From: Kurt Zeilenga Date: Wed, 23 Aug 2000 00:43:29 +0000 (+0000) Subject: Trim to those we (partially) implement X-Git-Tag: OPENLDAP_REL_ENG_2_0_0~25 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=3a979b8cea279cde827fcb5f38e713c53555e49a;p=openldap Trim to those we (partially) implement --- diff --git a/doc/drafts/draft-good-ldap-changelog-xx.txt b/doc/drafts/draft-good-ldap-changelog-xx.txt deleted file mode 100644 index 708c8552f6..0000000000 --- a/doc/drafts/draft-good-ldap-changelog-xx.txt +++ /dev/null @@ -1,449 +0,0 @@ - - - - -Change Record Object Class Definition Gordon Good -INTERNET-DRAFT Netscape Communications - 11 March 1998 - - Definition of an Object Class to Hold LDAP Change Records - Filename: draft-good-ldap-changelog-00.txt - -Status of this Memo - - This document is an Internet-Draft. 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.'' - - To learn the current status of any Internet-Draft, please check - the ``1id-abstracts.txt'' listing contained in the Internet- - Drafts Shadow Directories on ds.internic.net (US East Coast), - nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or - munnari.oz.au (Pacific Rim). - - This Internet Draft expires October 1st, 1998. - - - -Abstract - - In order to support more flexible replication methods, it is - desirable to specify some manner in which an LDAP client may retrieve - a set of changes which have been applied to an LDAP server's - database. The client, which may be another LDAP server, may then - choose to update its own replicated copy of the data. This document - specifies an object class which may be used to represent changes - applied to an LDAP server. It also specifies a method for - discovering the location of the container object which holds these - change records, so that clients and servers have a common rendezvous - point for this information. - - - -Background and Intended Usage - - This document describes an objectclass which can be used to represent - - - -Good March 11, 1998 [Page 1] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - changes which have been applied to a directory server. It also - suggests a common location for a container which holds these objects. - A client may update its local copy of directory information by - reading the entries within this container, and applying the changes - to its local database. - - The key words "MUST", "MAY", and "SHOULD" used in this document are - to be interpreted as described in [3]. - -New Attribute Types Used in the changeLogEntry Object Class - - ( 2.16.840.1.113730.3.1.5 - NAME 'changeNumber' - DESC 'a number which uniquely identifies a change made to a - directory entry' - SYNTAX 'INTEGER' - EQUALITY 'integerMatch' - ORDERING 'integerOrderingMatch' ) - - ( 2.16.840.1.113730.3.1.6 - NAME 'targetDN' - DESC 'the DN of the entry which was modified' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' ) - - ( 2.16.840.1.113730.3.1.7 - NAME 'changeType' - DESC 'the type of change made to an entry' - EQUALITY caseIgnoreMatch - SYNTAX 'DirectoryString' ) - - ( 2.16.840.1.113730.3.1.8 - NAME 'changes' - DESC 'a set of changes to apply to an entry' - SYNTAX 'OctetString' ) - - ( 2.16.840.1.113730.3.1.9 - NAME 'newRDN' - DESC 'the new RDN of an entry which is the target of a - modrdn operation' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' ) - - ( 2.16.840.1.113730.3.1.10 - NAME 'deleteOldRDN' - DESC 'a flag which indicates if the old RDN should be retained - as an attribute of the entry' - EQUALITY booleanMatch - - - -Good March 11, 1998 [Page 2] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - SYNTAX 'BOOLEAN' ) - - ( 2.16.840.1.113730.3.1.11 - NAME 'newSuperior' - DESC 'the new parent of an entry which is the target of a - moddn operation' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' ) - - -Schema Definition of the changeLogEntry Object Class - - ( 2.16.840.1.113730.3.2.1 - NAME 'changeLogEntry' - SUP top - STRUCTURAL - MUST ( - changeNumber $ targetDN $ changeType - ) - MAY ( - changes $ newRDN $ deleteOldRDN $ newSuperior - ) - ) - - - -Discussion of changeLogEntry Attributes: - - changeNumber: the change number, as assigned by the supplier. This - integer MUST strictly increase as new entries are added, and must - always be unique within a given server. Syntax: INTEGER - - targetdn: the distinguished name of the entry which was added, - modified or deleted. In the case of a modrdn operation, the targetdn - gives the DN of the entry before it was modified. Syntax: DN - - changeType: the type of change. One of: "add", "delete", "modify", - "modrdn". Later RFCs may define additional values for changeType. - Syntax: DirectoryString - - changes: the changes which were made to the directory server. These - changes are in LDIF format, which is described in [1]. - Syntax: OctetString - - newRDN: the new RDN (Relative Distinguished Name) of the entry, if the - changeType is "modrdn". If the changeType attribute does not have the - value "modrdn", then there should be no values contained in the newRDN - attribute. - - - -Good March 11, 1998 [Page 3] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - Syntax: DN - - deleteOldRDN: a flag which tells whether the old RDN of the entry - should be retained as a distinguished attribute of the entry, or - should be deleted. A value of "FALSE" indicates that the RDN should be - retained as a distinguished attribute, and a value of "TRUE" indicates - that it should not be retained as a distinguished attribute of the - entry. If any value other than "TRUE" or "FALSE" is contained in the - deleteOldRDN attribute, or if the deleteOldRDN contains multiple - values, the RDN should be retained as a distinguished attribute (that - is, "FALSE" is the default if no values are present, or if illegal - values are present). - Syntax: BOOLEAN - - newSuperior: if present, gives the name of the entry which - becomes the immediate superior of the existing entry. This optional - attribute reflects LDAPv3 functionality, and MUST NOT be generated - by LDAPv2 servers [2]. - Syntax: DN - - - -Discussion of the changeLogEntry object class - - The changeLogEntry object class is used to represent changes made to a - directory server. The set of changes made to a directory server, then, - is given by the ordered set of all entries within the changelog - container, ordered by changeNumber. - - A client may synchronize its local copy of a remote directory server's - contents by searching the remote server's changelog container for any - entries where the changenumber is greater than or equal to the last - change previously retrieved from that server. If the entry with the - changenumber matching the last change retrieved is not returned in the - search results, then the server's changelog has been trimmed. The - client must then fall back to reading the entire directory to bring its - copy in sync with the server's. - - Assuming that the client has successfully retrieved one or more changelog - entries from the server, it can then use the information contained in each - entry to update the corresponding entry (named by the targetDN attribute) - in its local copy of the database. - - Note that, due to access control restrictions, the client is not guaranteed - read access to the "changes" attribute. If the client discovers that the - "changes" attribute has no values, then it must read the entry given by - the targetDN attribute, possibly only retrieving attributes it deems - "interesting". However, in the case of delete and modrdn operations, there - - - -Good March 11, 1998 [Page 4] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - is never a "changes" attribute, so it is never necessary to read the target - entry in these cases. - - - -Examples of the changeLogEntry object class - - In each example below, the "changes" attribute is shown in plain text, - with embedded newlines. This is done for clarity. It is intended that - newlines be stored in the entry literally, not encoded in any way. - If a "changes" attribute value is stored in an LDIF file, it must - base-64 encoded. - - Example 1: A changeLogEntry representing the addition of a - new entry to the directory - - dn: changenumber=1923, cn=changelog - changenumber: 1923 - targetdn: cn=Barbara Jensen, ou=Accounting, o=Ace Industry, c=US - changetype: add - changes: cn: Barbara Jensen\ncn: Babs Jensen\nsn: Jensen\n - givenname: Barbara\ntelephonenumber: +1 212 555-1212\nmail: babs@ace.com\n - objectclass: top\nobjectclass: person\nobjectclass: organizationalPerson\n - objectclass: inetOrgPerson - - Example 2: A changeLogEntry representing the deletion of an entry - from the directory - - dn: changenumber=2933, cn=changelog - changenumber: 2933 - targetdn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US - changetype: delete - - Example 3: A changeLogEntry representing the modification of an entry - in the directory - - dn: changenumber=5883, cn=changelog - changenumber: 5883 - targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US - changetype: modify - changes: delete: telephonenumber\ntelephonenumber: 1212\n-\n - add: telephonenumber\ntelephonenumber: +1 212 555 1212\n- - - Example 4: A changeLogEntry representing a modrdn operation performed - on an entry in the directory - - dn: changenumber=10042, cn=changelog - changenumber: 10042 - - - -Good March 11, 1998 [Page 5] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - targetdn: cn=Bjorn Jensen, ou=Product Development, o=Ace Industry, c=US - changetype: modrdn - newrdn: cn=Bjorn J Jensen - deleteoldrdn: FALSE - - -Location of the container containing changeLogEntry objects - - For LDAPv3 servers, the location of the container which holds - changeLogEntry objects is obtained by reading the "changeLog" attribute - of a server's root DSE. For example, if the container's root is - "cn=changelog", then the root DSE must have an attribute named - "changeLog" with the value "cn=changelog". - - The "changelog" attribute is defined as follows: - - ( 2.16.840.1.113730.3.1.35 - NAME 'changelog' - DESC 'the distinguished name of the entry which contains - the set of entries comprising this server's changelog' - EQUALITY distinguishedNameMatch - SYNTAX 'DN' - ) - - For LDAPv2 servers, the name of the changelog container must be - "cn=changelog". - - -Differences from previous versions of this document - - Differences between draft-ietf-asid-changelog-00.txt and - draft-ietf-asid-changelog-01.txt - - 1) Fixed a deficiency in the syntax of the changeNumber attribute. The - attribute now has INTEGER syntax, with appropriate matching and - ordering rules defined. - - 2) Removed unneeded substring matching rules from the changeType and - deleteOldRDN attribute definitions. - - 3) Made use of MAY, SHOULD, etc. consistent with RFC 2119. - - 4) Renamed document (now an individual submission). - - 5) Changed syntax of "changes" attribute from "Binary" to "OctetString". - - 6) Removed references to X.500 supplier and consumer-initiated - replication. - - - -Good March 11, 1998 [Page 6] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - 7) Updated references to current drafts/proposed standards documents. - -Security Considerations - - Servers implementing this scheme MUST NOT allow the "changes" - attribute to be generally readable. The "changes" attribute contains - all modifications made to an entry, and some changes may contain - sensitive data, e.g. passwords. - - If a server does allow read access on the "changes: attribute to a - particular bound DN, then that DN should be trusted. For example, two - cooperating servers may exchange the password for some DN which is - granted read access to the "changes" attribute of the changeLog. This - would allow one server to retrieve changes and apply them directly to - its database. - - In situations where the "changes" attribute is not readable by a client, - that client may still use the entries in the changeLog to construct a - list of entry DNs which are known to have changed since the last time - the client synchronized. The client may then read each of those entries, - subject to whatever access control is in effect on the server, - and update its local copy of each entry. - - Servers implementing this scheme should disallow write access to the - changelog container object and all entries contained within. - - - -Acknowledgements - - This material is based in part upon work supported by the National - Science Foundation under Grant No. NCR-9416667. - - - -References - - [1] Good, G., "The LDAP Data Interchange Format", INTERNET-DRAFT - draft-good-ldap-ldif-03.txt, Netscape Communications Corp., March 1997, - - - [2] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access - Protocol (v3)", RFC 2251 Critical Angle, Inc., Netscape Communications Corp., - ISODE Consortium, July, 1997, - - - [3] S. Bradner, "Key Words for use in RFCs to Indicate Requirement - Levels", Harvard University, RFC 2119, March 1997, - - - -Good March 11, 1998 [Page 7] - -INTERNET-DRAFT Change Record Object Class 11 March 1998 - - - - - -Author's Address - - Gordon Good - Netscape Communications Corp. - 501 E. Middlefield Rd. - Mailstop MV068 - Mountain View, CA 94043, USA - Phone: +1 415 937-3825 - EMail: ggood@netscape.com - - This Internet Draft expires October 1st, 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Good March 11, 1998 [Page 8] - diff --git a/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt b/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt deleted file mode 100644 index 7e159eb220..0000000000 --- a/doc/drafts/draft-ietf-ldapext-acl-model-xx.txt +++ /dev/null @@ -1,2886 +0,0 @@ - - - - - - - -Internet-Draft E. Stokes -LDAP Extensions WG B. Blakley -Intended Category: Standards Track Tivoli Systems -Expires: 14 January 2001 D. Rinkevich - IBM - R. Byrne - Sun Microsystems - 14 July 2000 - - Access Control Model for LDAPv3 - - -STATUS OF THIS MEMO - -This document is an Internet-Draft and is in full -conformance with all provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet -Engineering Task Force (IETF), its areas, and its working -groups. Note that other groups may also distribute working -documents as Internet-Drafts. Internet-Drafts are draft -documents valid for a maximum of six months and may be -updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as -reference material or to cite them other than as "work in -progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt - -The list of Internet-Draft Shadow Directories can be -accessed at http://www.ietf.org/shadow.html. - -Comments and suggestions on this document are encouraged. -Comments on this document should be sent to the LDAPEXT -working group discussion list: - - ietf-ldapext@netscape.com - -COPYRIGHT NOTICE - -Copyright (C) The Internet Society (2000). All Rights -Reserved. - -ABSTRACT - -This document describes the access control model for the -Lightweight Directory Application Protocol V3 (LDAPv3) -directory service. It includes a description of the model, -the LDAP controls, and the extended operations to the LDAP -protocol. The current LDAP APIs are sufficient for most - - - -Stokes, et al Expires 14 January 2001 [Page 1] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -access control operations. An API (in a separate document) -is needed for the extended operation getEffectiveAccess. A -separate requirements document for access control exists -[REQTS]. The access control model used the requirements -documents as a guideline for the development of this -specification and are reflected in this specification to the -extent that the working group could agree on an access -control model. - - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", -"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and -"MAY" used in this document are to be interpreted as -described in [Bradner97]. - - - -1. Introduction - -The ability to securely access (replicate and distribute) -directory information throughout the network is necessary -for successful deployment. LDAP's acceptance as an access -protocol for directory information is driving the need to -provide an access control model definition for LDAP -directory content among servers within an enterprise and the -Internet. Currently LDAP does not define an access control -model, but one is needed to ensure consistent secure access, -replication, and management across heterogeneous LDAP -implementations. The major objective is to provide a simple, -usable, and implementable, but secure and efficient access -control model for LDAP while also providing the appropriate -flexibility to meet the needs of both the Internet and -enterprise environments and policies. This document defines -the model and the protocol extensions (controls and extended -operations). - -This draft does not (and cannot) fully specify the behavior -of the Access Control Model in a distributed environment -(e.g. propagating access control information across servers -and ACI administration) because there is no LDAP standard -defining how to distribute directory data between LDAP -servers. The behavior of the Access Control Model in -distributed environments is beyond the scope of this draft. - - - -2. The LDAPv3 Access Control Model - -Access Control mechanisms evaluate requests for access to -protected resources and make decisions about whether those -requests should be granted or denied. In order to make a - - - -Stokes, et al Expires 14 January 2001 [Page 2] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -grant/deny decision about a request for access to a -protected resource, an access control mechanism needs to -evaluate policy data. This policy data describes security- -relevant characteristics of the requesting subject and the -rules which govern the use of the target object. - -No mechanism is defined in this document for storage of -access control information at the server beyond indicating -that the attribute holding access control information is an -operational attribute. - -The access control mechanisms specified in this document are -neutral with respect to policy inheritance mechanisms, -explicit vs. implicit denial, and group nesting. - -The access control model defines - - - What flows on the wire for interoperability - - The existing LDAP protocol flows for ldap operations - are used to manipulate access control information. A - set of permissions and their semantics with respect to - ldap operations is defined. The permissions parallel - the types of ldap operations defined. What is - transmitted is exactly what is read back. Encoding of - access control information on the wire is per the - LDAPv3 specifications. - - There is an additional LDAP control and extended - protocol operation defined, getEffectiveRights. LDAP - clients use the control and extended operation to - manage and administer access control policy enforced by - LDAP servers. - - Servers may store access control information in any way - they choose. In particular, servers may use the access - control mechanisms of their datastores to store and - enforce LDAP access control, or they may implement - access control managers external to their datastores. - Datastores and external access control managers MAY - implement any access control rule syntax and semantics - they choose, but the semantics MUST be compatible with - those defined in the section titled "Operational - Semantics of Access Control Operations". - - - Attributes and classes for application portability of - access control information - - An access control information attribute (ldapACI) for - application portability: This attribute is used as - input to the LDAP APIs so access control information - - - -Stokes, et al Expires 14 January 2001 [Page 3] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - can be addressed uniformly independent of how that - information is addressed and stored at the server. - This same attribute appears in LDIF output for - interchange of access control information. - - An access control information subentry class - (ldapACISubEntry) and a set of attributes - (supportedAccessControlSchemes which is used in the - rootDSE and accessControlSchemes which is used in the - subentry ldapACISubEntry) to identity the access - control mechanisms supported by a server and in a given - part of the namespace, respectively. - - - An attribute in the rootDSE, discloseOnError, to - control whether it is permissible for the server to - return the name of an entry or attribute in an error - (or empty set) operation result. This closes a hole on - the ability to discover information you are not - authorized to discover. - - - A mechanism to control access to access control - information: The access control information attribute, - ldapACI, is used to control access to access control - information (controls access to itself). How to get an - initial ldapACI in the directory is server specific and - beyond the scope of this model. - -Servers can support multiple access control mechanisms, but -MUST be capable of supporting the LDAP Mechanism in the DIT -scoped by the rootDSE (entire server's DIT) for that server -and SHOULD be capable of supporting the LDAP mechanism in an -arbitrary part (subtree) of the DIT. - -The accessControlSchemes attribute in the ldapACISubEntry -indicates which access control mechanism is in effect for -the scope of that ldapACISubEntry. The -supportedAccessControlSchemes attribute in the rootDSE -indicates which acess control mechanisms are supported by -the server; those mechanisms are in effect in that server's -DIT unless overridden by a mechanism defined in a -ldapACISubEntry elsewhere in that DIT. - -Changing the value(s) of either the -supportedAccessControlSchemes or accessControlSchemes -attributes changes the mechanism(s) in effect for the scope -of those attributes (where scope is either that of the -rootDSE or ldapACISubEntry). - -Through the use of the mechanism rootDSE attribute and -ldapACI subentry, it is possible to run multiple mechanisms -in either the same subtree or separate subtrees. If two - - - -Stokes, et al Expires 14 January 2001 [Page 4] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -mechanisms are run in the same subtree, it is desirable that -the result be the same independent of mechanism, but -definition and discussion of this is beyond the scope of -this model. - - - -3. Access Control Mechanism Attributes - -Two attributes are defined to identify which access control -mechanisms are supported by a given server and by a given -subtree: supportedAccessControlSchemes and -accessControlSchemes. (We chose these names based on the -X.500 attribute, AccessControlScheme which is single-valued -and defined in X.501). - - -3.1 Root DSE Attribute for Access Control Mechanism - -The server advertises which access control mechanisms it -supports by inclusion of the 'supportedAccessControlSchemes' -attribute in the root DSE. This attribute is a list of -OIDs, each of which identify an access control mechanism -supported by the server. By default, these are also the -mechanisms in effect in subtrees beneath the root in that -server unless overridden by a ldapACISubEntry (see section -"Subentry Class Access Control Mechanism"). - - ( - NAME 'supportedAccessControlSchemes' - DESC list of access control mechanisms supported - by this directory server - SYNTAX LDAPOID - USAGE dSAOperation - ) - -The access control mechanism defined is: - LDAPv3 - -Other vendor access control mechanisms MAY be defined (by -OID) and are the responsibility of those vendors to provide -the definition and OID. - - -3.2 Root DSE Attribute for Control of Disclosing Errors - -The server specifies whether it is permissible for the name -of an entry or attribute to be disclosed in an error (or -empty) operation result. This rootDSE attribute is -discloseOnError. The default for discloseOnError is false -(0) or not to disclose on error. The lack of this attribute - - - -Stokes, et al Expires 14 January 2001 [Page 5] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -in the rootDSE is interpreted as the default. - - ( - NAME 'discloseOnError' - DESC specify whether to return the name of an - entry or attribute in an error (or - empty) operation result; 0=do not - disclose (default); 1=disclose - SYNTAX LDAPString - USAGE dSAOperation - - -3.3 Subentry Class Access Control Mechanism - -A given naming context MUST provide information about which -access control mechanisms are in effect for that portion of -the namespace. This information is contained in a subentry -(ldapACISubEntry class), derived from [SUBENTRY]. -ldapACISubEntry MAY be used to define the scope of an access -control mechanism. The value(s) held in the rootDSE -attribute, supportedAccessControlSchemes, are the mechanisms -in effect in subtrees beneath the root in that server unless -overridden in a ldapACISubEntry further down the tree held -by that server. The scope of that ldapACISubEntry is to the -end of the subtree held by that server or until another -ldapACISubEntry is encountered in that subtree held by that -server. The ldapACISubEntry class is defined as: - - - ( - NAME 'ldapACISubEntry' - DESC 'LDAP ACI Subentry class' - SUP ldapSubEntry STRUCTURAL - MUST ( accessControlSchemes ) - ) - -The accessControlSchemes attribute MUST be in each ldap -access control subentry entry associated with a naming -context whose access control mechanism is different from -adjacent naming contexts supported by that directory server. -accessControlSchemes lists the values (list of OIDs) that -define the access control mechanisms in effect for the scope -of that ldap access control subentry. Although, in general, -this attribute will define only a single mechanism (single -value), more than one mechanism MAY be in effect for the -scope of that subentry. - - ( - NAME 'accessControlSchemes' - DESC list of access control mechanisms supported - in this subtree - - - -Stokes, et al Expires 14 January 2001 [Page 6] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - SYNTAX LDAPOID - USAGE dSAOperation - ) - - - -4. The Access Control Information Attribute (ldapACI) - -The access control information attribute, ldapACI, is -defined as: - - ( - NAME 'ldapACI' - DESC 'ldap access control information' - EQUALITY caseIgnoreMatch - SYNTAX directoryString - USAGE directoryOperation - ) - -The intent of the attribute definition is to design a common -interchange format. Any given LDAP server should be able to -translate the below defined attribute into meaningful -operation requests. Each server should be able to understand -the attribute; there should not be any ambiguity into what -any part of the syntax means. - -While the end goal is to have a common behavior model -between different LDAP server implementations, the attribute -definition alone will not ensure identical ACL processing -behavior between servers. The semantics of how a server -interprets the ACI syntax are defined in the "Operational -Semantics of Access Control" section of this document. -Additionally, while the server must recognize and act on the -attribute when received over the wire, there are no -requirements for the server to physically store this -attribute. - -The attribute definition maintains an assumption that the -receiving server supports inheritance within the security -model. If the server does not support inheritance, the -receiving server must expand any inherited information based -on the scope flag. If the server does not support partial -inheritance and both the entry and subtree scope are used, -then entry is the prevailing scope. (It is possible for two -values in the ldapACI attribute to have different scopes -given the syntax of ldapACI; one might contain 'entry' and -another might contain 'subtree'. This implies that some -ldapACI values inherit down the DIT and othersdo not - hence -partial inheritance of the ldapACI attribute.) - -The attribute is defined so access control information (ACI) - - - -Stokes, et al Expires 14 January 2001 [Page 7] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -can be addressed in a server independent of server -implementation. This attribute is used in typical LDAP APIs -and in LDIF output of ACI. This attribute may be queried or -set on all directory objects. The BNF and definitions are -given below. - - -4.1 The BNF - - -4.1.1 ACI String Representation - - Values of this syntax are encoded according to the - following BNF which follows the BNF encoding - conventions described in [ABNF]: - - ldapACI = scope "#" rights "#" attr "#" subject - - scope = "entry" / "subtree" - - rights = (("grant:" / "deny:") permissions) / - ("grant:" permissions ";deny:" permissions) - - permissions = [permission *("," permission)] - - permission = "a" / ; add - "d" / ; delete - "e" / ; export - "i" / ; import - "n" / ; renameDN - "b" / ; browseDN - "t" / ; returnDN - "r" / ; read - "s" / ; search - "w" / ; write (mod-add) - "o" / ; obliterate (mod-del) - "c" / ; compare - "m" / ; make - - attr = "[all]" / "[entry]" / (attribute *("," attribute)) - - attribute = ; OID syntax (1.3.6.1.4.1.1466.115.121.1.38) - ; from [ATTR] - - subject = ["authnLevel:" authnLevel ":"] - (("authzID-" authzID) / - ("role:" dn) / - ("group:" dn) / - ("subtree:" dn) / - ("ipAddress:" ipAddress) / - "public:" / - - - -Stokes, et al Expires 14 January 2001 [Page 8] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - "this:") - - authnLevel = "any" / - "simple" / - sasl - - sasl = "sasl:" - ("any" / - mechanism) - - mechanism = ; sasl mechanism from 4.2 of [LDAPv3] - - authzID = ; authzID from [AuthMeth] repeated below - ; for convenience - - authzId = dnAuthzId / uAuthzId - - ; distinguished-name-based authz id. - dnAuthzId = "dn:" dn - - dn = utf8string ; with syntax defined in [UTF] - - ; unspecified userid, UTF-8 encoded. - uAuthzId = "u:" userid - userid = utf8string ; syntax unspecified - - ipAddress = printableString - ; dotted decimal form (e.g. 10.0.0.6) - ; or use wildcards such as 12.3.45.* to - ; specify a specific subnetwork - ; or 123.45.6.*+255.255.255.115 to - ; specify a subnetmask - ; or use a wildcard domain name such as - ; *.airius.com to specify a specific - ; DNS domain - - printableString ; printableString syntax from [ATTR] - - -Note that the colon following the "public" and "this" -subject options exist only to simplify string parsing. - -Note also that per [AuthMeth], authzID may be expanded in -the future. - -See section titled 'ACI Examples' for examples of the string -representation. - - - - - - - -Stokes, et al Expires 14 January 2001 [Page 9] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -4.1.2 ACI Binary Representation - - The following ASN.1 data type is used to represent this - syntax when transferred in binary form: - - ldapACI ::= SEQUENCE { - scope ENUMERATED { - entry (0), - subtree (1) }, - rights SEQUENCE OF CHOICE { - grant [0] Permissions, - deny [1] Permissions }, - attr CHOICE { - all [0] NULL, - entry [1] NULL, - attributes [2] SEQUENCE OF Attribute }, - subject SEQUENCE { - authnLevel CHOICE { - any [0] NULL, - simple [1] NULL, - sasl [2] CHOICE { - any [0] NULL, - mechanism [1] LDAPString -- from [LDAPv3] - } - }, - subject CHOICE { - dn [0] DN, - user [1] utf8String - role [1] DN, - group [2] DN, - subtree [3] DN, - ipAddress [4] IPAddress, - public [6] NULL, - this [7] NULL }, } -- may be expanded - per [AuthMeth] - - Permissions ::= SEQUENCE OF ENUMERATED { - add (0), - delete (1), - export (2), - import (3), - renameDN (4), - browseDN (5), - returnDN (6), - read (7), - search (8), - write (9), - obliterate (10), - compare (11), - make (12) } - - - - -Stokes, et al Expires 14 January 2001 [Page 10] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - Attribute ::= AttributeType -- from [LDAPv3] - - IPAddress ::= PrintableString -- (e.g. 10.0.0.6) - - - -4.2 The Components of ldapACI Attribute - -This section defines components that comprise the access -control information attribute, ldapACI. - - -4.2.1 Scope - -Two scopes for access control information are defined: - - - entry - the access control information in the ldapACI - attribute applies only to the entry in which it is - contained - - - subtree - the access control information in the ldapACI - attribute applies to each entry down the subtree unless - it is overridden by an entry-specific ldapACI whose - values are more specific. - -Use of prescriptive ACIs and scoping via use of a -ldapACISubEntry is outside the scope of this document. - - -4.2.2 Access Rights and Permissions - -Access rights can apply to an entire object or to attributes -of the object. Access can be granted or denied. Either or -both of the actions "grant" | "deny" may be used when -creating or updating ldapACI. - -Each of the LDAP access permissions are discrete. One -permission does not imply another permission. The -permissions which apply to attributes and the entry parallel -the type of ldap operations that can be performed. - -Permissions which apply to attributes: - - r Read Read attribute values - w Write Modify-add values - o Obliterate Modify-delete values - s Search Search entries with specified attributes - c Compare Compare attributes - m Make Make attributes on a new entry below - this entry - - - - -Stokes, et al Expires 14 January 2001 [Page 11] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - 1. r Read - - If granted, permits attributes and values to be - returned in a read or search operation. - - 2. w Write - - If granted, permits attributes and values to be added - in a modify operation. - - 3. o Obliterate - - If granted, permits attributes and values to be - deleted in a modify operation. - - 4. s Search - - If granted, permits attributes and values to be - included in a search operation. - - 5. c Compare - - If granted, permites attributes and value to be used - in a compare operation. - - 6. m Make - - The attribute permission "m" is required for all - attributes that are placed on an object when it is - created. Just as the "w" and "o" permissions are used - in the Modify operation, the "m" permission is used in - the Add operation. Additionally, note that "w" and "o" - have no bearing on the Add operation and "m" has no - bearing on the Modify operation. Since a new object - does not yet exist, the "a" and "m" permissions needed - to create it must be granted on the new object's - parent. This differs from "w" and "o" which must be - granted on the object being modified. The "m" - permission is distinct and separate from the "w" and - "o" permissions so that there is no conflict between - the permissions needed to add new children to an entry - and the permissions needed to modify existing children - of the same entry. - -Note: Modify-replace values of an attribute requires "w" -and "o" permission. - -Permissions that apply to an entire entry: - - - a Add Add an entry below this entry - - - -Stokes, et al Expires 14 January 2001 [Page 12] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - d Delete Delete this entry - e Export Export entry & subordinates to new - location - i Import Import entry & subordinates from some - location - n RenameDN Rename an entry's DN - b BrowseDN Browse an entry's DN - t ReturnDN Allows DN of entry to be disclosed in - an operation result - - - 1. a Add - - If granted, permits creation of an entry in the DIT - subject to control on all attributes and values to be - placed in the new entry at time of creation. In order - to add an entry, permission must also be granted to - add at least the mandatory attributes. - - 2. d Delete - - If granted, permits the entry to be removed from the - DIT regardless of controls on attributes within the - entry. - - 3. e Export - - If granted, permits an entry and its subordinates (if - any) to be exported; that is, removed from the current - location and placed in a new location subject to the - granting of suitable permission at the destination. - If the last RDN is changed, Rename is also required at - the current location. In order to export an entry or - its subordinates, there are no prerequisite - permissions to contained attributed, including the RDN - attributes; this is true even when the operation - causes new attribute values to be added or removed as - the result of the changes of RDN. - - 4. i Import - - If granted, permits an entry and its suordinates (if - any) to be imported; that is, removed from some other - location and placed a t the location to which the - permission applies subject to the granting of suitable - permissions at the source location. In order to - import an entry or its subordinates, there are no - prerequisite permissions to contained attributed, - including the RDN attributes; this is true even when - the operation causes new attribute values to be added - or removed as the result of the changes of RDN. - - - -Stokes, et al Expires 14 January 2001 [Page 13] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - 5. n RenameDN - - Granting Rename is necessary for an entry to be - renamed with a new RDN, taking into account - consequential changes to the distinguished names of - subordinate entries, if any; if the name of the - superior is unchanged, the grant is sufficient. In - order to rename an entry, there are no prerequisite - permissions to contained attributed, including the RDN - attributes; this is true even when the operation - causes new attribute values to be added or removed as - the result of the changes of RDN. - - 6. b BrowseDN - - If granted, permits entries to be accessed using - directory operations which do not explicitly provide - the name of the entry. - - 7. t ReturnDN - - If granted, allows the distinguished name of the entry - to be disclosed in the operation result. - -All permissions (for grant and deny) for an attribute/entry -and a given subject MUST be contained within one ldapACI -value, i.e. (in abbreviated form) - - ldapACI: ...grant OID.attr1 subjectA - ldapACI: ...deny OID.attr1 subjectA - -must be ldapACI: ...grant ... deny... OID.attr1 subjectA - -Using the defined BNF it is possible for the permission -string to be empty. The ACI - - ldapACI: subtree#grant#OID.attr1#group:cn=Dept XYZ,c=US - - ldapACI: subtree#grant:r,s#[all]#group:cn=Dept XYZ,c=US - -means that this group (Dept XYZ) is granted permission to -read and search all attributes except OID.attr1 because -OID.attr1 is more specific than "[all]". - - -4.2.3 Attributes - -Attribute describes an attribute name in the form of a -dotted decimal OID for that . If the string (OID) -refers to an attribute not defined in the given server's -schema, the server SHOULD report an error. "[entry]" means - - - -Stokes, et al Expires 14 January 2001 [Page 14] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -the permissions apply to the entire object. This could mean -actions such as delete the object, or add a child object. -"[all]" means the permission set apply to all attributes of -the entry. - -If the keyword "[all]" and another attribute are both -specified within an ACI, the more specific permission set -for the attribute overrides the less specific permission set -for "[all]". - - -4.2.4 Subjects and Associated Authentication - -The following subjects are defined and MUST be supported: - - - authzID, defined per [authmeth] - - - group, defined as the distinguished name of a - groupOfNames or groupOfUniqueNames entry - - - role - - - subtree, defined as the distinguished name of a non- - leaf node in the DIT - - - ipAddress, - - - public, defined as public access - - - this, defined as the user whose name matches that of - the entry being accessed - -Other parties MAY define other subjects. It is the -responsibility of those parties to provide the definition. - -A subject may be qualified by the type of authentication -required for access to a given attribute(s) or entry. If no -authnLevel is present, then no specific type of -authentication is additionally required for access. If -authnLevel is specified, then that type of authentication is -additionally required for access. The authnLevels parallel -the authentication mechanisms specified for LDAPv3: simple, -SASL (any type of SASL mechanism), and a SASL-specific -mechanism. The authnLevel of is not an acceptable mechanism -for this case) as part of obtaining access. - - -4.3 Grant/Deny Evaluation Rules - -The decision whether to grant or deny a client access to a -particular piece of information is based on several pieces - - - -Stokes, et al Expires 14 January 2001 [Page 15] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -of information found within the ldapaci value. Throughout -the decision making process, there are guiding principals. - - - Specificity: More specific policies MUST override less - specific ones (e.g. individual user entry in ACI takes - precedence over group entry). - - - Deny takes precedence over Grant. - - - When there are conflicting ACI values, deny takes - precedence over grant. - - - Deny is the default when there is no access control - information. - -Precendence of Scope Types (highest to lowest) - - - entry - - - subtree - -Precedence of Subjects within a Scope (highest to lowest): - - - ipAddress - - - authzID, this - - - group, role, this, public - - - subtree, public - -Although other types MAY be defined given the BNF, use of -the well-known types aids in interoperability and -operational consistency. - -Access Decision algorithm: - - 1. Determine all the ldapACI values which could apply to - the target DN which is being accessed. This is the DN - of the entry which is being queried in a search, - modified, deleted, etc. When determining all the - ldapACI values, the scope field should be used. All - ldapACI values with a scope of 'entry' take precedence - over ldapACI values with a scope of 'subtree'. - - 2. Determine which ldapACI (of the set determined in step - 1) apply to the bound DN. This is determined by - looking at the subject (combination of subject type - and subject value) and bind type. If no bind is in - effect (this is possible in ldapv3), then treat this - lack of bind as if bound as anonymous. Start with the - - - -Stokes, et al Expires 14 January 2001 [Page 16] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - most specific subject type. If at any time, at least - one ldapACI value exists for a specificity level, then - processing stops; the exception here is 'this' because - this may also be combined with group to use power of - 'this'. Evaluation should take place on set of - ldapACI values which are all of the same specificity - level. Subjects of the same precedence are combined - using union semantics. - - 3. Evaluate the remaining ldapACI values and determine a - grant/deny decision. If conflicting ldapACI value - exists for the same attribute, or attributes (i.e. one - ldapACI grants permission and another denies - permission), then deny takes precedence over grant. - For example, if one is granted permission to - "objectclass" in one ldapACI value by being a member - of group cn=Admin, and denied permission by being a - member of cn = NontrustedAdmins, then the bound user - would not receive permission to objectclass. - - The rule of specificity also applies to the - attributes. If one is denied permission to "[ all ]" - attributes, but granted permission to "objectclass" - then the more specific value of "objectclass" takes - precedence over the less specific value of "[ all ] ". - In this case the user would be granted permission to - "objectclass" but denied permission to all other - attributes. - - - -5. Required Permissions for each LDAP Operation - -This section defines the required permissions for each LDAP -operation but even if these requirements are satisfied the -server MAY refuse to carry out the operation due to other -implementation specific security considerations. For -example, a server may refuse to modify an entry because the -database where that entry resides is in read only mode. -Another example might be that although the access control is -available to the userPassword attribute a server may refuse -modifications due to some server specific policy governing -access to passwords. - -Here, we specify the rights required by a user when -performing an LDAP operation in terms of the LDAP -permissions specified in section 6.1. Recall that "a, d, -e, i, n, b,t" are permissions that apply to entries as a -whole while permissions "r, s, w, o, c, m" apply to -attributes within entries. - - - - -Stokes, et al Expires 14 January 2001 [Page 17] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -Required permissions for LDAP extended operations and LDAP -controls are beyond the scope of this draft. - -There is a requirement that a user should not be able to -infer the existence of data in the Directory, if the user -does not have the required access rights to that data. An -example of this requirement would be in a hosting -environment where you would not want any users from the coke -subtree to be able to even discover that the pepsi tree was -hosted on the same server. This "discloseOnError" feature -will be set once for server in the rootDSE advertised by the -attribute discloseOnError. The default for discloseOnError -is false (0). The lack of this attribute in the rootDSE is -interpreted as the default. The details of its effects are -addressed below, operation by operation. - -For the following, assume that the authorization identity of -the user doing the operation is authzID. - - -5.1 Bind Operation - -This draft does not require any permissions to allow a bind -operation to proceed. - - -5.2 Search Operation - -Recall that the parameters of the Search operation per RFC -2251 [LDAPv3] Section 4.5 are: - - SearchRequest ::= [APPLICATION 3] SEQUENCE { - baseObject LDAPDN, - scope ENUMERATED { - baseObject (0), - singleLevel (1), - wholeSubtree (2) }, - derefAliases ENUMERATED { - neverDerefAliases (0), - derefInSearching (1), - derefFindingBaseObj (2), - derefAlways (3) }, - sizeLimit INTEGER (0 .. maxInt), - timeLimit INTEGER (0 .. maxInt), - typesOnly BOOLEAN, - filter Filter, - attributes AttributeDescriptionList } - -Suppose a server is processing a search request from user -authzID with parameters as above and is processing the entry -with dn candidateDN to decide if it may be returned or not. - - - -Stokes, et al Expires 14 January 2001 [Page 18] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -Then the permissions required by authzID that need to be -evaluated are as follows: - - - 1. permission "b" to the entry candidateDN - - If this permission is not granted then the dn - candidateDN MUST not be returned nor any attribute - type nor attribute value from this entry. - - If this permission is granted then the dn candidateDN - MAY be returned. - - Note: The idea of the "b" permission is to say "a user - has discovery rights" at a certain entry in the - directory. Assuming that the further required - permissions below are satisfied then having "b" right - is enough to allow the server to return candidateDN. - Of course candidateDN contains in it's components, - attributes and attribute values for all the ancestors - of candidateDN. This can lead to the slightly odd - situation that we can discover the naming attribute of - an entry and that attribute's value by virtue of - having the required searching permissions to it's - child but not by searching the entry directly. - - 2. permission "s" to each attribute appearing in a - presence test during the evaluation of the search - filter. permission "r" to each attribute appearing in - non-presence tests (see rfc1960, section 3: - equalityMatch, substrings, greaterOrEquial, - lessOrEqual, present, approxMatch, extensibleMatch) - during the evaluation of the search filter. - - The above statement covers the case where the - attributes are being evaluated as part of an - extensibleMatch (RFC 2251 section 4.5.1) which appears - in the filter. In the case where the dnAttributes - field of the extensibleMatch is true then we do not - require any access checks to the attributes of the dn - candidateDN as access to these is taken to be granted - by the "b" permission, which has already been required - above. - - If there is an attribute in a filter element to which - the required permission is not granted then that - filter element evaluates to "Undefined" of the three- - valued-logic of X.511(93). - - Note A: Although both "r" and "s" permissions will - typically be granted to attributes we keep both - - - -Stokes, et al Expires 14 January 2001 [Page 19] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - permissions as there are cases where the distinction - is useful. For example, the ability to grant the - right to discover that a user entry contains a - userPassword attribute, but not to read it's value - ("s" but not "r"). The converse, granting "r" but not - "s" permission is less easy to motivate. - - Note B: There is an unusual behaviour with respect to - naming attributes illustrated in the following - example: - - Suppose I have "b" rights to cn=fred,o=sun.com and "r" - rights to attribute objectclass but not "r" rights to - cn then with search filter (objectclass=*) I get back - the dn and objectclass (and so can see the value of - cn), but with a search filter of (cn=fred) I do not - get anything. - - 3. permission "r" to each attribute in the attribute list - - AttributeDescriptionList (or all attributes in the - entry candidateDN if AttributeDescriptionList is *) - whose type and/or value will be returned. - - Note: The presence of an attribute in an entry is only - ever volunteered by the server if "r" permission is - granted to it, though a user may infer the presence of - an attribute with "s" permission by using a presence - test on that attribute in the search filter. - - 4. permission "t" to the entry candidateDN - - If this permission is not granted then the dn - candidateDN MUST NOT be returned. If the server knows - of an alias for the entry, this alias may be returned - instead. If no alias name is available then the entry - candidateDN MUST be omitted from the search results. - - - 5. Disclose on error for the Search operation - - If every entry in the scope of the search fails to - satisfy item 1 (browse right on the candidate entry) - or item 2 (right to use the filter on that entry) and - if discloseOnError is not granted to the baseObject - entry then the operation MUST fail with a "no such - object error" and the matchedDN of the LDAPResult MUST - be set to "". If every entry in the scope of the - search fails to satisfy items 1 or 2 above and - discloseOnError is granted to the baseObject then the - empty set of results is returned. - - - -Stokes, et al Expires 14 January 2001 [Page 20] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -5.3 Modify Operation - -Recall that the parameters of the Modify operation per -RFC2251 [LDAPv3] Section 4.6 are: - - ModifyRequest ::= [APPLICATION 6] SEQUENCE { - object LDAPDN, - modification SEQUENCE OF SEQUENCE { - operation ENUMERATED { - add (0), - delete (1), - replace (2) }, - modification AttributeTypeAndValues } } - - - AttributeTypeAndValues ::= SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - -Then the permissions required by authzID that need to be -evaluated are as follows: - - - 1. permission "w" to each attribute being added to object - - If this permission is not granted to such an - attribute, then the operation MUST fail. In this - case, if discloseOnError is not granted to the entry - then "no such object" error is returned; if - discloseOnError is granted to the entry and a - duplicate attribute value is being added then - "attribute value already exists" error is returned; if - discloseOnError is granted to the entry and no - duplicate value is being added then an "insufficient - access" error is returned. - - 2. permission "o" to each attribute for which a value is - being deleted from object - - If this permission is not granted to such an attribute - then the operation MUST fail. In this case, if - discloseOnError is not granted to the entry then "no - such object" error is returned; if discloseOnError is - granted to the entry and the attribute or one of the - values to be deleted does not exist then a "no such - attribute or value" error is returned; if - discloseOnError is granted to the entry and the - attribute and all values specified to be deleted exist - then an "insufficient access" error is returned. - - - - - -Stokes, et al Expires 14 January 2001 [Page 21] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - 3. permissions "o" and "w" to each attribute being - replaced in object - - If one of these these permissions is not granted to - such an attribute then the operation MUST fail. In - this case, if discloseOnError is not granted to the - entry then a "no such object" error is returned; if - discloseOnError is granted to the entry then - "insufficient access" error is returned. - - -5.4 Add Operation - -Recall that the parameters of the Add operation per RFC2251 -[LDAPv3] Section 4.7 are: - - AddRequest ::= [APPLICATION 8] SEQUENCE { - entry LDAPDN, - attributes AttributeList } - - - AttributeList ::= SEQUENCE OF SEQUENCE { - type AttributeDescription, - vals SET OF AttributeValue } - -Then the permissions required by authzID that need to be -evaluated are as follows: - - permission "a" to the parent of entry - - The access rights required for the creation of a root - entry in the Directory are beyond the scope of this - document. They will be vendor specific. - - 1. permission "m" to the parent of entry for each - attribute being added to entry - -If any of these permissions are not granted then the -operation MUST fail. In this case if discloseOnError is on -and the entry to be added does not already exist then -"insufficient access" is returned. If it does exist then -"Entry already exists" is returned. If discloseOnError is -off then "No such object" is returned (meaning the parent -object). - -If they are all granted then the operation MAY proceed. - -Note: We require "m" permission to each attribute to prevent -an entry from aquiring "unintended" rights (via group or -role membership), to stop a "rogue" ACI being added that -would prevent even admins deleting the entry and general - - - -Stokes, et al Expires 14 January 2001 [Page 22] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -consistency with the MODIFY operation. - -Note: The access rights required for the creation of the -first entry in the directory are beyond the scope of this -document. - - -5.5 Delete Operation - -Recall that the parameters of the Delete operation per -RFC2251 [LDAPv3] Section 4.10 are: - - DelRequest ::= [APPLICATION 10] LDAPDN - -Then the permissions required by authzID that need to be -evaluated are as follows: - - - 1. permission "d" to the entry in the Delete request - -If this permission is not granted, then the operation MUST -fail. In this case if discloseOnError is on and the entry -to be deleted exists then "insufficient access" is returned. -If it does not exist then "No such Object" is returned. If -discloseOnError is off then "No such object" is returned -(meaning the parent object). - -If this permission is granted, then the operation MAY -proceed. - -Note: One could also require the "o" permission to be -granted to allow the operation to proceed, but customer -experience has shown that the requirement of the additional -permission is not useful nor expected, and X.500 requires -only the "d" permission. - - -5.6 Modify DN Operation - -Recall that the parameters of the Modify DN operation per -RFC2251 [LDAPv3] Section 4.6 are: - - ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { - entry LDAPDN, - newrdn RelativeLDAPDN, - deleteoldrdn BOOLEAN, - newSuperior [0] LDAPDN OPTIONAL } - -Then the permissions required by authzID that need to be -evaluated are as follows: - - - - -Stokes, et al Expires 14 January 2001 [Page 23] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - 1. If newSuperior is not present (ie. only the RDN is - being renamed) then permission "n" to entry is - required. - - 2. If newSuperior is present then permission "e" to entry - and permission "i" to newSuperior are required. - -If any of these permissions are not granted then the -operation MUST fail. In this case, if discloseOnError is on -then an "insufficient access error" is returned. Otherwise, -"No such object" is returned. - -If they are all granted then the operation MAY proceed. - -Note A: We do not require any additional permissions in the -case where deleteoldrdn is TRUE. - -Note B: These permissions allow the naming attribute of an -entry (or entries) to be changed even though "o" and "w" -permissions are not available on the entry. Distinguishing -the permissions like this allows us to grant permissions for -the ModifyDN operation, but not the Modify operation and -vice versa. - - -5.7 Compare Operation - -Recall that the parameters of the Compare operation per -RFC2251 [LDAPv3] Section 4.10 are: - - CompareRequest ::= [APPLICATION 14] SEQUENCE { - entry LDAPDN, - ava AttributeValueAssertion } - -Then the permissions required by authzID that need to be -evaluated are as follows: - - - 1. permission "c" to the attribute in entry on which the - comparison is being made. - -If any of these permissions are not granted then the -operation MUST fail. In this case, if discloseOnError is on -then an "insufficient access error" is returned. Otherwise, -"No such object" is returned. - -If they are all granted then the operation MAY proceed. - - - - - - - -Stokes, et al Expires 14 January 2001 [Page 24] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -5.8 Abandon Operation - -Recall that the parameters of the Abandon operation per -RFC2251 [LDAPv3] Section 4.6 are: - - AbandonRequest ::= [APPLICATION 16] MessageID - -authzID always has the right to send an Abandon Operation -for an operation he previously initiated. - - -5.9 Extended Operation - -Recall that the parameters of the Extended operation per -RFC2251 [LDA{v3] Section 4.12 are: - - ExtendedRequest ::= [APPLICATION 23] SEQUENCE { - requestName [0] LDAPOID, - requestValue [1] OCTET STRING OPTIONAL } - -The access required for an Extended Operation is beyond the -scope of this document. The required access will normally -be defined by the implementor of the extended request. - - - -6. Required Permissions for Handling Aliases and References - - -Use of aliases and referrals are part of LDAPv3. However, -neither is particularly well-defined. Alias -objects/attributes are defined in RFC 2256 as derived from -X.500, but LDAPv3 does not explicitly define its semantics -or behavior. X.500 does define alias semantics and behavior -with respect to access control; we define its behavior in -LDAPv3 based on the X.511, section 7.11.1. Referrals and -knowledge information are still under design in LDAPv3; they -are defined in X.500, however, X.500 punts on their -semantics and behavior with respect to access control. We -define their semantics and behavior in LDAPv3 in terms that -should be independent of the future LDAPv3 definition of -referrals and knowledge information. - - -6.1 ACI Distribution - -Currently there is no LDAP standard defining how to -distribute directory data between LDAP servers. Consequently -this draft cannot fully specify the behavior of the Access -Control Model in a distributed environment. The case of -distribution via referrals is treated in the "Referrals" - - - -Stokes, et al Expires 14 January 2001 [Page 25] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -section below. In the case of chaining (where one LDAP -server forwards a request to another on behalf of a client) -then it is server specific how the access control model -behaves in this environment. Similarly it is server specific -how the server determines whether the chaining of an -operation is permitted in the first place. For example, the -implementation may choose to regard the local naming context -and the remote subordinate naming context as seperate Access -Control Specific Areas, or it may regard the DIT as one -Access Control Specific Area and implement mechanisms to -propagate access control information between the two -servers. The behavior of the Access Control Model in -distributed environments such as these is beyond the scope -of this draft. - - -6.2 Aliases - -There are two things to protect with respect to aliases: -the real name of the aliased object and the location of the -server holding it. - -If alias de-referencing is required in the process of -locating a target entry, no specifc permissions are -necessary for alias de-referencing to take place. Access -control is enforced at the object pointed to by the alias. - -If alias de-referencing would result in a -continuationReference (e.g. from a search operation), then -browse permission is required to the alias entry and read -permission is required to the 'aliasedObjectName' attribute. -Requiring these permission closes the hole of discovery. - - -6.3 Referrals - -If a referral is to be followed, no specifc permissions are -necessary for the ldap client to follow the referral. Access -control is enforced at the referenced object. If a referral -is returned, then browse is required on the entry and read -permission is required to the attribute containing the -referral (we cannot name this attribute exactly today -because there are no RFCs on this - only drafts). If the -server implements a default referral, then no special -permissions are required to read and return that referral. -Requiring these permissions closes the hole of discovery. -In the default case, it is assumed that a default referral -is public. - - - - - - -Stokes, et al Expires 14 January 2001 [Page 26] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -7. Controlling Access to Access Control Information - -The ldapACI attribute is used to specify control for who has -permission to set/change access control information -(ldapACI). The ldapACI attribute/OID is just another -attribute described with a scope, set of rights and -permissions, and subject as a value of the ldapACI -attribute. (See the example in the "ACI Examples" section). - -If the policy for controlling the ldapACI attribute is not -specified for any object in the tree, behavior is -implementation defined. For instance, if no object anywhere -in the tree defines the access for ldapACI within the -ldapACI attribute, then the server could simply assert that -the 'root DN' is considered the policy owner (controller for -controlling access control) for all objects. - - - -8. ACI Examples - -Note that in the examples, the form "OID." refers -to the OID in dotted decimal form for the attribute -. This shorthand notation is used only for the -examples. In implementation, the dotted decimal form of the -OID is used. - - -8.1 Attribute Definition - -The following examples show the access required to control -access to the ldapACI attribute. The first example shows -controlling the access control on an individual entry and -its attributes. The second example shows controlling the -access control on a subtree. - - ldapACI: entry#grant:r,w# - OID.ldapACI#authnLevel:any:role:cn=aciAdmin - - ldapACI: subtree#grant:r,w# - OID.ldapACI#authnLevel:any:role:cn=aciAdmin - -The next example shows a ldapACI attribute where a group -"cn=Dept XYZ, c=US" is being given permissions to read, -search, and compare attribute attr1. The permission applies -to the entire subtree below the node containing this ACI. -Authentication of a specified type is not required. - - ldapACI:subtree#grant;r,s,c# - OID.attr1#group:cn=Dept XYZ,c=US - - - - -Stokes, et al Expires 14 January 2001 [Page 27] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -The next example shows an ACI attribute where a role -"cn=SysAdmins,o=Company" is being given permissions to add -objects below this node and read, search, and compare -attributes attr2 and attr3. The permission applies to the -entire subtree below the node containing this ACI. - - ldapACI: subtree#grant:a# - [entry]#role:cn=SysAdmins,o=Company - - ldapACI: subtree#grant:r,s,c# - OID.attr2#role:cn=SysAdmins,o=Company - - ldapACI: subtree#grant:r,s,c# - OID.attr3#role:cn=SysAdmins,o=Company - - -8.2 Modifying the ldapACI Values - -Modify-Replace works as defined in the ldap operation -modify. If the attribute value does not exist, create the -value. If the attribute does exist, replace the value. If -the ldapACI value is replaced, all ldapACI values are -replaced. - -A given ldapACI for an entry: - - ldapACI: subtree#deny:r,w#[all]#group:cn=Dept ABC - - ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ - -perform the following change: - - dn: cn=someEntry - changetype: modify - replace: ldapACI - ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN - -The resulting ACI is: - -ldapACI: subtree#grant:r,w#[all]#group:cn=Dept LMN - -( ldapACI values for Dept XYZ and ABC are lost through the -replace ) - -During an ldapmodify-add, if the ACI does not exist, the -create the ACI with the specific ldapACI value(s). If the -ACI does exist, then add the specified values to the given -ldapACI. For example a given ACI: - -ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ - - - - -Stokes, et al Expires 14 January 2001 [Page 28] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -with a modification: - - dn: cn=someEntry - changetype: modify - add: ldapACI - ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ - -would yield an multi-valued ACI of: - - ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ - - ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ - -To delete a particular ACI value, use the regular ldapmodify -- delete syntax - -Given an ACI of: - - ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ - ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ - - dn: cn = some Entry - changetype: modify - delete: ldapACI - ldapACI: subtree#grant:r#OID.attr1#group:cn=Dept XYZ - -would yield a remaining ACI on the server of - -ldapACI: subtree#grant:r,w#[all]#group:cn=Dept XYZ - -The attributes which are defined for access control -interchange may be used in all LDAP operations. - -Within the ldapmodify-delete operation, the entire acl may -be deleted by specifying - - dn: cn = some Entry - changetype: modify - delete: ldapACI - -In this case, the entry would then inherit its ACI from some -other node in the tree depending on the server inheritance -model. - -Similarly, if all values of ldapACI are deleted, then the -access control information for that entry is defined by that -implementation's inheritance model. - - - - - - - -Stokes, et al Expires 14 January 2001 [Page 29] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -8.3 Evaluation - -These examples assume that the ldapACI entries listed in -each example are the only ACI which applies to the entry in -question; if backing-store ACI also exists, the effective -policy may be different from that listed in each example. -See section 10 for a discussion of the semantics of ldapACI -entries when backing-store ACI administration is also used. - -Assume cn=jsmith is a member of group cn=G1. Assume -cn=jsmith is a member of group cn=G2. - - Example #1 - dn: o=XYZ, c=US - ldapACI: subtree#grant:r#attr1 - #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US - ldapACI: subtree#grant:w#attr1 - #group:cn=G1,ou=ABC,o=XYZ,c=US - - What rights does cn=jsmith have to attr1 of o=XYZ,c=US? - Read (r) access; authzID is higher precedence than - group. - - - Example #2 - dn: o=XYZ, c=US - ldapACI: subtree#grant:r#attr2 - #group:cn=G1,ou=ABC,o=XYZ,c=US - ldapACI: subtree#grant:w#attr2 - #group:cn=G2,ou=ABC,o=XYZ,c=US - - What rights does cn=jsmith have to attr2 of o=XYZ,c=US? - Read-write (r,w) access; ACI is combined because both - subjects (group) have same precedence. - - - Example #3 - dn: o=XYZ, c=US - ldapACI: subtree#grant:r,w#attr3 - #group:cn=G1,ou=ABC,o=XYZ,c=US - ldapACI: subtree#deny:w#attr3#group:cn=G2,ou=ABC,o=XYZ,c=US - - What rights does cn=jsmith have to attr3 of o=XYZ, c=US? - Read access; write is denied (deny has precedence over - grant). - - - Example #4 - dn: o=XYZ, c=US - ldapACI: subtree#grant:w#attr4 - #authzID-dn:cn=jsmith,ou=ABC,o=XYZ,c=US - - - -Stokes, et al Expires 14 January 2001 [Page 30] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - ldapACI: subtree#grant:r#attr4#subtree:ou=ABC,ou=XYZ,c=US - - What rights does cn=jsmith have to attr4 of o=XYZ, c=US? - Write (w); rights given to an authzID take precedence - over those given to a subtree. - - - Example #5 - dn: o=XYZ, c=US - ldapACI: subtree#grant:m#OID.attr5 - #authzID-dn:cn=jsmith,o=ABC,c=US - ldapACI: subtree#grant:m#OID.cn - #authzID-dn:cn=jsmith,o=ABC,c=US - ldapACI: subtree#grant:m#OID.sn - #authzID-dn:cn=jsmith,o=ABC,c=US - ldapACI: subtree#grant:a#[entry] - #authzID-dn:#cn=jsmith,o=ABC,c=US - - What rights does cn=jsmith have to o=XYZ, c=US? - Make(m) on attributes attr5, cn, and sn and Add(a) - on the entry. These are the minimal yet sufficient - permissions to create a new object, - cn=New, o=XYZ, c=US with values for the attr5, cn, - and sn attributes. This example illustrates how the - "m" permission can be used to limit the attributes - that can be created on a new entry. - - Example #6 - dn: c=US - ldapACI: subtree#grant:m#[all]#subtree:c=US - dn: o=XYZ, c=US - ldapACI: subtree#grant:a#[entry]# - authzID-dn:cn=jsmith,o=ABC,c=US - - What rights does cn=jsmith have to o=XYZ, c=US? - Make(m) on attributes all attributes and Add(a) on the - entry. These are sufficient permissions to create a new - object, cn=New, o=XYZ, c=US with values any desired - attributes. For administrators who do not wish to limit - the attributes that can be created on new entries, this - example shows how a single ldapACI at the top of the - domain solves the problem. - - - -9. Operational Semantics of Access Control Operations - -The semantics of access control operations described in this -document are defined operationally in terms of "histories". -A history is a sequence of actions (x1, x2, ..., xN). - - - - -Stokes, et al Expires 14 January 2001 [Page 31] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -9.1 Types of actions - -We consider five types of actions: - - - LDAP Access Control Policy Update actions: invocations - of ldap modify when used to add, delete, or replace the - aci attribute; invocations of ldap add when used to add - an entry with an aci attribute. A LDAP Access Control - Policy Update action may replace the policy (by - completely replacing the aci attribute with new policy - information) or it may grant or deny specific rights - while leaving others unaffected. - - - LDAP Access Control Policy Query operations: - invocations of ldap search when used to retrieve the - aci attribute; invocations of ldap search with the - getEffectiveRightsRequest control; invocations of the - ldapGetEffectiveRightsRequest extended operation. - - - Datastore Access Control Policy Update Actions: any - operation implemented by the server which LDAP is using - as its datastore which changes the access policy - enforced with respect to attempts to access LDAP - directory entries and their attributes. - - - LDAP Access Request operations: invocations of LDAP - entry or attribute access operations (Read, Update, - Search, Compare, etc...). - - - Other operations: anything else, including Datastore - operations which do not change the access policy - enforced by the server. - - -9.2 Semantics of Histories - -The semantics of histories are defined as follows: - - - LDAP Update (Replace), LDAP Query - - The Query will show that the subject has all rights - granted by the Update operation, and no rights not - granted by the Update operation. - - - LDAP Update (Grant), LDAP Query - - The Query will show that the subject has all rights - granted by the Update operation. The Query may show - that the subject also has other rights not granted by - the Update operation, depending on the policy in force - before the Update operation. - - - -Stokes, et al Expires 14 January 2001 [Page 32] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - - LDAP Update (Deny), LDAP Query - - The Query will show that the subject does not have any - right denied by the Update operation. The Query may - show that the subject has rights not denied by the - Update operation, depending on the policy in force - before the Update operation. - - - LDAP Update (Replace), LDAP Access Request - - The Request will succeed if it requires only rights - granted to the requesting subject by the Update - operation. The Request will fail if it requires any - right not granted by the Update operation. - - - LDAP Update (Grant), LDAP Access Request - - The Request will succeed if it requires only rights - granted to the requesting subject by the Update - operation. The Request may succeed if it requires - rights not granted by the Update operation, depending - on the policy in force before the Update operation. - - - LDAP Update (Deny), LDAP Access Request - - The Request will fail if it requires any right denied - to the requesting subject by the Update operation. If - the Request requires only rights which were not denied - by the Update operation, it may succeed, depending on - the policy in force before the Update operation. - - - LDAP Update (Replace), Other, LDAP Query - - The Query will show that the subject has all rights - granted by the Update operation, and no rights not - granted by the Update operation. - - - LDAP Update (Grant), Other, LDAP Query - - The Query will show that the subject has all rights - granted by the Update operation. The Query may show - that the subject also has other rights not granted by - the Update operation, depending on the policy in force - before the Update operation. - - - LDAP Update (Deny), Other, LDAP Query - - The Query will show that the subject does not have any - right denied by the Update operation. The Query may - show that the subject has rights not denied by the - Update operation, depending on the policy in force - - - -Stokes, et al Expires 14 January 2001 [Page 33] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - before the Update operation. - - - LDAP Update (Replace), Other, LDAP Access Request - - The Request will succeed if it requires only rights - granted to the requesting subject by the Update - operation. The Request will fail if it requires any - right not granted by the Update operation. - - - LDAP Update (Grant), Other, LDAP Access Request - - The Request will succeed if it requires only rights - granted to the requesting subject by the Update - operation. The Request may succeed if it requires - rights not granted by the Update operation, depending - on the policy in force before the Update operation. - - - LDAP Update (Deny), Other, LDAP Access Request - - The Request will fail if it requires any right denied - to the requesting subject by the Update operation. If - the Request requires only rights which were not denied - by the Update operation, it may succeed, depending on - the policy in force before the Update operation. - - - LDAP Update (Replace), Datastore Policy Update, LDAP - Query - - The result of the Query is not defined. - - - LDAP Update (Grant), Datastore Policy Update, LDAP - Query - - The result of the Query is not defined. - - - LDAP Update (Deny), Datastore Policy Update, LDAP Query - - The result of the Query is not defined. - - - LDAP Update (Replace), Datastore Policy Update, LDAP - Access Request - - The result of the Access Request is not defined. - - - LDAP Update (Grant), Datastore Policy Update, LDAP - Access Request - - The result of the Access Request is not defined. - - - LDAP Update (Deny), Datastore Policy Update, LDAP - Access Request - - - -Stokes, et al Expires 14 January 2001 [Page 34] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - The result of the Access Request is not defined. - - - -10. Access Control Parameters for LDAP Controls & Extended -Operations - -This section defines the parameters used in the access -control LDAP controls and extended operations in this -document. - -targetDN specifies the initial directory entry in DN syntax -on which the control or extended operation is performed. - -whichObject specifies whether the access control information -(in the get effective rights control) which is retrieved is -for the target directory entry (ENTRY) or the target -directory entry and its subtree (SUBTREE). - -rights in the get effective rights control or extended -operation response is of the form specified in the BNF for -. - -subject is a LDAP string that defines the subject. Access -control is get/set on a subject. The syntax of the subject -is the same as the subject field in the BNF. - - - -11. Access Control Information (ACI) Controls - -The access control information controls provide a way to -manipulate access control information in conjunction with a -LDAP operation. One LDAP control is defined. This control -allows access control information to be retrieved while -manipulating other directory information for that entry. -The control is: - - - getEffectiveRights to obtain the effective rights for a - given directory entry(s) for a given subject during a - ldap_search operation - -11.1 getEffectiveRights Control - - -11.1.1 Request Control - -This control may only be included in the ldap_search -message as part of the controls field of the -LDAPMessage, as defined in Section 4.1.12 of [LDAPv3]. - - - - -Stokes, et al Expires 14 January 2001 [Page 35] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -The controlType is set to . The -criticality MAY be either TRUE or FALSE (where absent is -also equivalent to FALSE) at the client's option. The -controlValue is an OCTET STRING, whose value is the BER -encoding of a value of the following SEQUENCE: - - getEffectiveRightsRequest ::= SEQUENCE { - effectiveRightsRequest SEQUENCE OF SEQUENCE { - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - subject in BNF> | "*" - } - } - -The effectiveRightsRequest is a set of sequences that state -the whichObject (entry or entry plus subtree) and specifics -of the control request to be performed. A "*" in the subject -field specifies that all DN types are to be used in -returning the effective rights. This control is applied to -the filter and scope set by the ldap_search operation, i.e. -base, one-level, subtree. So the attributes/values returned -are defined by the ldap_search operation. - -11.1.2 Response Control - -This control is included in the ldap_search_response message -as part of the controls field of the LDAPMessage, as defined -in Section 4.1.12 of [LDAPv3]. - -The controlType is set to . There is no -need to set the criticality on the response. The -controlValue is an OCTET STRING, whose value is the BER -encoding of a value of the following SEQUENCE: - - getEffectiveRightsResponse ::= { - result ENUMERATED { - success (0), - operationsError (1), - unavailableCriticalExtension (12), - noSuchAttribute (16), - undefinedAttributeType (17), - invalidAttributeSyntax (21), - insufficientRights (50), - unavailable (52), - unwillingToPerform (53), - other (80) - } - } - - - - -Stokes, et al Expires 14 January 2001 [Page 36] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -The effective rights returned are returned with each entry -returned by the search result. The control response for -ldap_search is: - - PartialEffectiveRightsList ::= SEQUENCE OF SEQUENCE { - rights in BNF>, - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - subject < see in BNF > - } - -Although this extends the search operation, there are no -incompatibilities between versions. LDAPv2 cannot send a -control, hence the above structure cannot be returned to a -LDAPv2 client. A LDAPv3 client cannot send this request to -a LDAPv2 server. A LDAPv3 server not supporting this -control cannot return the additional data. - -11.1.3 Client-Server Interaction - -The getEffectiveRightsRequest control requests the rights -that MUST be in effect for requested directory -entry/attribute based on the subject DN. The server that -consumes the search operation looks up the rights for the -returned directory information based on the subject DN and -returns that rights information. - -There are six possible scenarios that may occur as a result -of the getEffectiveRights control being included on the -search request: - - - 1. If the server does not support this control and the - client specified TRUE for the control's criticality - field, then the server MUST return - unavailableCriticalExtension as a return code in the - searchResponse message and not send back any other - results. This behavior is specified in section 4.1.12 - of [LDAPv3]. - - 2. If the server does not support this control and the - client specified FALSE for the control's criticality - field, then the server MUST ignore the control and - process the request as if it were not present. This - behavior is specified in section 4.1.12 of [LDAPv3]. - - 3. If the server supports this control but for some - reason such as cannot process specified family and the - client specified TRUE for the control's criticality - - - -Stokes, et al Expires 14 January 2001 [Page 37] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - field, then the server SHOULD do the following: return - unavailableCriticalExtension as a return code in the - searchResult message. - - 4. If the server supports this control but for some - reason such as cannot process specified family and the - client specified FALSE for the control's criticality - field, then the server should process as 'no rights - returned for that family' and include the result - Unavailable in the getEffectiveRightsResponse control - in the searchResult message. - - 5. If the server supports this control and can return the - rights per the family information, then it should - include the getEffectiveRightsResponse control in the - searchResult message with a result of success. - - 6. If the search request failed for any other reason, - then the server SHOULD omit the - getEffectiveRightsResponse control from the - searchResult message. - -The client application is assured that the correct rights -are returned for scope of the search operation if and only -if the getEffectiveRightsResponse control returns the -rights. If the server omits the getEffectiveRightsResponse -control from the searchResult message, the client SHOULD -assume that the control was ignored by the server. - -The getEffectiveRightsResponse control, if included by the -server in the searchResponse message, should have the -getEffectiveRightsResult set to either success if the rights -are returned or set to the appropriate error code as to why -the rights could not be returned. - -The server may not be able to return a right because it may -not exist in that directory object's attribute; in this -case, the rights request is ignored with success. - - -12. Access Control Extended Operation - -An extended operation, get effective rights, is defined to -obtain the effective rights for a given directory entry for -a given subject. This operation may help with the -management of access control information independent of -manipulating other directory information. - - - - - - - -Stokes, et al Expires 14 January 2001 [Page 38] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -12.1 LDAP Get Effective Rights Operation - -ldapGetEffectiveRightsRequest ::= [APPLICATION 23] SEQUENCE -{ - requestName [0] , - requestValue [1] OCTET STRING OPTIONAL } - - where - - requestValue ::= SEQUENCE { - targetDN LDAPDN, - updates SEQUENCE OF SEQUENCE { - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - attr SEQUENCE { - attr in BNF > - }, - subject < see in BNF > | "*" - } - } - - -The requestName is a dotted-decimal representation of the -OBJECT IDENTIFIER corresponding to the request. The -requestValue is information in a form defined by that -request, encapsulated inside an OCTET STRING. - -The server will respond to this with an LDAPMessage -containing the ExtendedResponse which is a rights list. - -ldapGetEffectiveRightsResponse ::= [APPLICATION 24] SEQUENCE -{ - COMPONENTS OF LDAPResult, - responseName [10] OPTIONAL, - effectiveRights [11] OCTET STRING OPTIONAL } - - where - - effectiveRights ::= SEQUENCE OF SEQUENCE { - rights in BNF>, - whichObject ENUMERATED { - LDAP_ENTRY (1), - LDAP_SUBTREE (2) - }, - subject < see in BNF > - } - -If the server does not recognize the request name, it MUST -return only the response fields from LDAPResult, containing - - - -Stokes, et al Expires 14 January 2001 [Page 39] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -the protocolError result code. - - - -13. Security Considerations - -This document proposes protocol elements for transmission of -security policy information. Security considerations are -discussed throughout this draft. Because subject security -attribute information is used to evaluate decision requests, -it is security-sensitive information and must be protected -against unauthorized modification whenever it is stored or -transmitted. - -Interaction of access control with other directory functions -(other than the ones defined in this document) are not -defined in this document, but instead in the documents where -those directory functions are defined. For example, the -directory replication documents should address the -interaction of access control with the replication function. - - - -14. References - -[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory -Access Protocol (v3)", RFC 2251, December 1997. - -[ECMA] ECMA, "Security in Open Systems: A Security -Framework" ECMA TR/46, July 1988. - -[REQTS] Stokes, Byrne, Blakley, "Access Control Requirements -for LDAP", RFC 2820, May 2000. - -[ATTR] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight -Directory Access Protocol (v3)": Attribute Syntax -Definitions, RFC 2252, December 1997. - -[UTF] M. Wahl, S. Kille, "Lightweight Directory Access -Protocol (v3)": A UTF-8 String Representation of -Distinguished Names", RFC 2253, December 1997. - -[Bradner97] Bradner, Scott, "Key Words for use in RFCs to -Indicate Requirement Levels", RFC 2119. - -[AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. -Morgan, "Authentication Methods for LDAP", RFC 2829, May -2000. - -[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax -Specifications: ABNF", RFC 2234, November 1997. - - - -Stokes, et al Expires 14 January 2001 [Page 40] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - -ACKNOWLEDGEMENT - -This is to acknowledge the numerous companies and individuals who have -contributed their valuable help and insights to the development of this -specification. - - -AUTHOR(S) ADDRESS - - Ellen Stokes Bob Blakley - Tivoli Systems Tivoli Systems - 6300 Bridgepoint Parkway 6300 Bridgepoint Parkway - Austin, TX 78731 Austin, TX 78731 - USA USA - mail-to: estokes@tivoli.com mail-to: blakley@tivoli.com - phone: +1 512 436 9098 phone: +1 512 436 1564 - fax: +1 512 436 1199 fax: +1 512 436 1199 - - - Debbie Rinkevich Robert Byrne - IBM Sun Microsystems - 11400 Burnet Rd 29 Chemin du Vieux Chene - Austin, TX 78758 Meylan ZIRST 38240 - USA France - mail-to: djbrink@us.ibm.com mail-to: rbyrne@france.sun.com - phone: +1 512 838 1960 phone: +33 (0)4 76 41 42 05 - fax: +1 512 838 8597 - - - - - - - - - - - - - - - - - - - - - - - - - - - -Stokes, et al Expires 14 January 2001 [Page 41] - - - - - -Internet-Draft Access Control Model 14 July 2000 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Stokes, et al Expires 14 January 2001 [Page 42] - - - - - - - - - - CONTENTS - - - 1. Introduction....................................... 2 - - 2. The LDAPv3 Access Control Model.................... 2 - - 3. Access Control Mechanism Attributes................ 5 - 3.1 Root DSE Attribute for Access Control - Mechanism.................................... 5 - 3.2 Root DSE Attribute for Control of Disclosing - Errors....................................... 5 - 3.3 Subentry Class Access Control Mechanism...... 6 - - 4. The Access Control Information Attribute - (ldapACI).......................................... 7 - 4.1 The BNF...................................... 8 - 4.1.1 ACI String Representation 8 - 4.1.2 ACI Binary Representation 10 - 4.2 The Components of ldapACI Attribute.......... 11 - 4.2.1 Scope 11 - 4.2.2 Access Rights and Permissions 11 - 4.2.3 Attributes 14 - 4.2.4 Subjects and Associated - Authentication 15 - 4.3 Grant/Deny Evaluation Rules.................. 15 - - 5. Required Permissions for each LDAP Operation....... 17 - 5.1 Bind Operation............................... 18 - 5.2 Search Operation............................. 18 - 5.3 Modify Operation............................. 21 - 5.4 Add Operation................................ 22 - 5.5 Delete Operation............................. 23 - 5.6 Modify DN Operation.......................... 23 - 5.7 Compare Operation............................ 24 - 5.8 Abandon Operation............................ 25 - 5.9 Extended Operation........................... 25 - - 6. Required Permissions for Handling Aliases and - References......................................... 25 - 6.1 ACI Distribution............................. 25 - 6.2 Aliases...................................... 26 - 6.3 Referrals.................................... 26 - - 7. Controlling Access to Access Control - Information........................................ 27 - - 8. ACI Examples....................................... 27 - 8.1 Attribute Definition......................... 27 - 8.2 Modifying the ldapACI Values................. 28 - 8.3 Evaluation................................... 30 - - - - - i - - - - - - - - - - - - - 9. Operational Semantics of Access Control - Operations......................................... 31 - 9.1 Types of actions............................. 32 - 9.2 Semantics of Histories....................... 32 - -10. Access Control Parameters for LDAP Controls & - Extended Operations................................ 35 - -11. Access Control Information (ACI) Controls.......... 35 - 11.1 getEffectiveRights Control................... 35 - 11.1.1 Request Control 35 - 11.1.2 Response Control 36 - 11.1.3 Client-Server Interaction 37 - -12. Access Control Extended Operation.................. 38 - 12.1 LDAP Get Effective Rights Operation.......... 39 - -13. Security Considerations............................ 40 - -14. References......................................... 40 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ii - - - - - - - - - - - - -Full Copyright Statement - -Copyright (C) The Internet Society (2000).á 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 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. - - - - - - - - - - - - - - - - - - - - - - - - - iii - - - - - diff --git a/doc/drafts/draft-ietf-ldapext-ldapv3-dupent-xx.txt b/doc/drafts/draft-ietf-ldapext-ldapv3-dupent-xx.txt deleted file mode 100644 index f7cb49acfe..0000000000 --- a/doc/drafts/draft-ietf-ldapext-ldapv3-dupent-xx.txt +++ /dev/null @@ -1,412 +0,0 @@ - - -LDAPEXT Working Group J. Sermersheim -Internet Draft Novell, Inc -Document: draft-ietf-ldapext-ldapv3-dupent-03.txt March 2000 -Category: Proposed Standard - - - LDAP Control for a Duplicate Entry Representation of Search Results - - -1. Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [1]. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. Internet-Drafts are draft documents valid for a maximum of - six months and may be updated, replaced, or obsoleted by other - documents at any time. It is inappropriate to use Internet- Drafts - as reference material or to cite them other than as "work in - progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -2. Abstract - - This document describes a Duplicate Entry Representation control - extension for the LDAP Search operation. By using the control with - an LDAP search, a client requests that the server return separate - entries for each value held in the specified attributes. For - instance, if a specified attribute of an entry holds multiple - values, the search operation will return multiple instances of that - entry, each instance holding a separate single value in that - attribute. - -3. Overview - - The Server-Side Sorting control [SSS] allows the server to order - search result entries based on attribute values (sort keys). It - does not allow one to specify behavior when an attribute contains - multiple values. The default behavior, as outlined in 7.9 of - [X.511], is to use the smallest value as the sort key. - - An application may need to produce an ordered list of entries, - sorted by a multi-valued attribute, where each attribute value is - represented in the list. In order to do this, a separate control is - needed which causes the set of entries to be expanded sufficiently - to represent each attribute value prior to sorting. - - - Sermersheim Standards Track - Expires Sep 2000 Page 1 - -LDAP Control for a Duplicate Entry Representation of Search Results - - - This document describes controls, which allow duplicate entries in - the result set of search, where each entry represents a distinct - value of a given multiple valued attribute. - - An example of this would be a sorted list of all telephone numbers - in an organization. Because any entry may have multiple telephone - numbers, and the list is to be sorted by telephone number, the list - must be able to contain duplicate entries, each with its own unique - telephone number. - - Another example would be an application that needs to display an - ordered list of all members of a group. It would use this control - to create a result set of duplicate groupOfNames entries, each with - a single, unique value in its member attribute. - - The key words "MUST", "SHOULD", and "MAY" used in this document - carry the meanings described in [Bradner97]. - -4. The Controls - - Support for the controls is advertised by the presence of their OID - in the supportedControl attribute of a server's root DSE. The OID - for the request control is "2.16.840.1.113719.1.27.101.1" and the - OID for the response control is "2.16.840.1.113719.1.27.101.2". - -4.1 Request Control - - This control is included in the searchRequest message as part of the - controls field of the LDAPMessage, as defined in Section 4.1.12 of - [LDAPv3]. - - The controlType is set to "2.16.840.1.113719.1.27.101.1". The - criticality MAY be set to either TRUE or FALSE. The controlValue is - an OCTET STRING, whose value is the BER encoding of the following - type: - - DuplicateEntryRequest ::= AttributeDescriptionList - - The "AttributeDescriptionList" data type is described in 4.1.5 of - [LDAPv3] and describes a list of 0 or more AttributeDescription - types as also described in 4.1.5 of [LDAPv3]. Both definitions are - repeated here for convenience: - - AttributeDescriptionList ::= SEQUENCE OF - AttributeDescription - - AttributeDescription ::= [ ";" ] - - While processing a search request, a server implementation examines - this list. If a specified attribute exists in an entry to be - returned by search, one instance of that entry per attribute value - is returned. In this case, the specified attribute in each entry - - -Sermersheim Standards Track - Expires Sep 2000 Page 2 - -LDAP Control for a Duplicate Entry Representation of Search Results - - - holds a single, unique value from the original set of values of that - attribute. - - An AttributeDescription should only occur once in the list. If an - AttributeDescription is included in the DuplicateEntryRequest - multiple times, the server should return an unwillingToPerform error - in the DuplicateEntryResponse. - - When two or more attribute types are specified by this control, the - number of duplicate entries is the combination of all values in each - attribute. Because of the potential complexity involved in servicing - multiple attribute types, server implementations MAY choose to - support a limited number of attribute types in the control. - - There is a special case where either no attributes are specified, or - an attribute description value of "*" is specified. In this case, - all attributes are used. (The "*" allows the client to request all - user attributes in addition to specific operational attributes). - -4.2 Response Control - - This control is included in the searchResultDone message as part of - the controls field of the LDAPMessage, as defined in Section 4.1.12 - of [LDAPv3]. - - The controlType is set to "2.16.840.1.113719.1.27.101.2". The - criticality is FALSE (MAY be absent). The controlValue is an OCTET - STRING, whose value is the BER encoding of the following SEQUENCE: - - DuplicateEntryResponse ::= SEQUENCE { - result ENUMERATED { - success (0), - operations error (1), -- server internal failure - timeLimitExceeded (3), -- time limit reached before - -- attribute values could be - -- processed - sizeLimitExceeded (4), -- size limit reached as a - -- result of this control - adminLimitExceeded (11), -- result set too large for - -- server to handle - noSuchAttribute (16), -- unrecognized attribute - -- description - busy (51), - unwillingToPerform (53), - other (80) }, - attributeType AttributeDescription OPTIONAL } - - A result field is provided here to allow feedback in the case where - the criticality of the request control is FALSE, and the server - could not process the control - yet it could complete the search - operation successfully. If the request control's criticality is - TRUE, and the server cannot process the control, the resultCode of - the LDAPResult is used to report the error. - -Sermersheim Standards Track - Expires Sep 2000 Page 3 - -LDAP Control for a Duplicate Entry Representation of Search Results - - - - attributeType MAY be set to the value of the first attribute type - specified by the DuplicateEntryRequest that was in error. The - client MUST ignore the attributeType field if the result is success. - -5. Protocol Examples - -5.1 Simple example - - This example will show this control being used to produce a list of - all telephone numbers in the "Acting" organizational unit of "Looney - Tunes". Let's say the following three entries exist in this - organization; - - dn: cn=Bugs Bunny,ou=Acting,o=Looney Tunes - telephoneNumber: 555-0123 - - dn: cn=Daffy Duck,ou=Acting,o=Looney Tunes - telephoneNumber: 555-8854 - telephoneNumber: 555-4588 - telephoneNumber: 555-5884 - - dn: cn=Porky Pig,ou=Acting,o=Looney Tunes - telephoneNumber: 555-9425 - telephoneNumber: 555-7992 - - First an LDAP search is specified with a baseDN of "ou=Acting, - o=Looney Tunes ", subtree scope, filter set to "telephoneNumber=*". - A DuplicateEntryRequest control is attached to the search, - specifying "telephoneNumber" as the attribute description, and the - search request is sent to the server. - - The set of search results returned by the server would then consist - of the following entries: - - dn: cn=Bugs Bunny,ou=Acting,o=Looney Tunes - telephoneNumber: 555-0123 - - dn: cn=Daffy Duck,ou=Acting,o=Looney Tunes - telephoneNumber: 555-8854 - - dn: cn=Daffy Duck,ou=Acting,o=Looney Tunes - telephoneNumber: 555-4588 - - dn: cn=Daffy Duck,ou=Acting,o=Looney Tunes - telephoneNumber: 555-5884 - - dn: cn=Porky Pig,ou=Acting,o=Looney Tunes - telephoneNumber: 555-9425 - - dn: cn=Porky Pig,ou=Acting,o=Looney Tunes - telephoneNumber: 555-7992 - - -Sermersheim Standards Track - Expires Sep 2000 Page 4 - -LDAP Control for a Duplicate Entry Representation of Search Results - - - Note that it is not necessary to use an attribute type in this - control that is specified in the search filter. This example only - does so, because the result was to obtain a list of telephone - numbers. - -5.2 Specifying multiple attributes - - A more complicated example involving multiple attributes will result - in more entries. If we assume these entries in the directory: - - dn: cn=Bugs Bunny,ou=Acting,o=Looney Tunes - givenName: Bugs - mail: bbunny@looneytunes.com - - dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes - givenName: Elmer - givenName: Doc - mail: efudd@looneytunes.com - mail: bunnyhunter@nra.org - - And both "mail" and "givenName" are specified as attribute types in - this control, the resulting set of entries would be this: - - dn: cn=Bugs Bunny,ou=Acting,o=Looney Tunes - givenName: Bugs - mail: bbunny@looneytunes.com - - dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes - givenName: Elmer - mail: efudd@looneytunes.com - - dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes - givenName: Elmer - mail: bunnyhunter@nra.org - - dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes - givenName: Doc - mail: efudd@looneytunes.com - - dn: cn=Elmer Fudd,ou=Acting,o=Looney Tunes - givenName: Doc - mail: bunnyhunter@nra.org - -5.3 Listing the members of a groupOfNames - - This example shows how the controls can be used to turn a single - groupOfNames entry into multiple duplicate entries. LetÆs say this - is our groupOfNames entry: - - dn: cn=Administrators,o=acme - cn: Administrators - member: cn=aBaker,o=acme - member: cn=cDavis,o=acme - -Sermersheim Standards Track - Expires Sep 2000 Page 5 - -LDAP Control for a Duplicate Entry Representation of Search Results - - - member: cn=bChilds,o=acme - member: cn=dEvans,o=acme - - We could set our search base to "cn=Administrators,o=acme", filter - to "objectClass=*", use an object scope (to restrict it to this - entry) and send the duplicateEntryRequest control with "member" as - its attribute value. The resulting set would look like this: - - dn: cn=Administrators,o=acme - member: cn=aBaker,o=acme - - dn: cn=Administrators,o=acme - member: cn=cDavis,o=acme - - dn: cn=Administrators,o=acme - member: cn=bChilds,o=acme - - dn: cn=Administrators,o=acme - member: cn=dEvans,o=acme - - This list can then be sorted by member and displayed (also by - member) in a list. - -6 Relationship to other controls - - This control is intended (but not limited) to be used with the - Server Side Sorting control [SSS]. By pairing this control with the - Server Side Sorting control, One can produce a set of entries, - sorted by attribute values, where each attribute value is - represented in the sorted set. Server implementations should ensure - that this control is processed before sorting the result of a - search, as this control alters the result set of search. - - This control may also be used with the Virtual List View [VLV] - control (which has a dependency on the Server Side Sort control). - The nature of the dependency between the VLV control and the Sort - control is such that the Sorting takes place first. Because the sort - happens first, and because this control is processed before the sort - control, the impact of this control on the VLV control is minimal. - Some server implementations may need to carefully consider how to - handle the typedown functionality of the VLV control when paired - with this control. The details of this are heavily implementation - dependent and are beyond the scope of this document. - -7. Notes for Implementers - - Both client and server implementations should be aware that using - this control could potentially result in a very large set of search - results. Servers MAY return an adminLimitExceeded result in the - response control due to inordinate consumption of resources. This - may be due to some a priori knowledge such as a server restriction - of the number of attribute types in the request control that it's - - -Sermersheim Standards Track - Expires Sep 2000 Page 6 - -LDAP Control for a Duplicate Entry Representation of Search Results - - - willing to service, or it may be due to the server attempting to - service the control and running out of resources. - - Client implementations must be aware that search entries returned, - when using this control will contain a subset of the values of any - specified attribute. - -8. Acknowledgments - - The author gratefully thanks the input and support of participants - of the LDAP-EXT working group. - -9. References - - [LDAPv3] - Wahl, M, S. Kille and T. Howes, "Lightweight Directory Access - Protocol (v3)", Internet Standard, December, 1997. - Available as RFC2251. - - [SSS] - Wahl, M, A. Herron and T. Howes, "LDAP Control Extension for Server - Side Sorting of Search Results", Internet Draft, March, 1998. - Available as draft-ietf-ldapext-sorting-02.txt. - - [VLV] - Boreham, D, Sermersheim, J, Anantha, A, Armijo, M, "LDAP Extensions - for Scrolling View Browsing of Search Results", Internet Draft, - June, 1999. - Available as draft-ietf-ldapext-ldapv3-vlv-03.txt. - - - [X.511] - ITU-T Rec. X.511, "The Directory: Abstract Service Definition", - 1993. - - [Bradner97] - Bradner, Scott, "Key Words for use in RFCs to Indicate Requirement - Levels", Internet Draft, March, 1997. - Available as RFC2119. - -10. Author's Address - - Jim Sermersheim - Novell, Inc. - 122 East 1700 South - Provo, Utah 84606, USA - jimse@novell.com - +1 801 861-3088 - - - - - - -Sermersheim Standards Track - Expires Sep 2000 Page 7 diff --git a/doc/drafts/draft-ietf-ldapext-matchedval-xx.txt b/doc/drafts/draft-ietf-ldapext-matchedval-xx.txt deleted file mode 100644 index d35e2ff666..0000000000 --- a/doc/drafts/draft-ietf-ldapext-matchedval-xx.txt +++ /dev/null @@ -1,405 +0,0 @@ -Internet-Draft David Chadwick -LDAPExt WG University of Salford -Intended Category: Standards Track Sean Mullan - Sun Microsystems -Expires: 1 January 2001 1 July 2000 - - -Returning Matched Values with LDAPv3 - - - -STATUS OF THIS MEMO - -This document is an Internet-Draft and is in full conformance with -all the provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet Engineering -Task Force (IETF), its areas, and its working groups. Note that other -groups may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference -material or to cite them other than as "work in progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt. - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. - -This Internet-Draft expires on 1 January 2001. Comments and -suggestions on this document are encouraged. Comments on this -document should be sent to the LDAPExt working group discussion list: - ietf-ldapext@netscape.com -or directly to the authors. - - -ABSTRACT - -This document describes a control for the Lightweight Directory -Access Protocol v3 that is used to return a subset of attribute -values from an entry, specifically, only those values that match a -"values return" filter. Without support for this control, a client -must retrieve all of an attribute's values and search for specific -values locally. - - -1. Introduction - -When reading an attribute from an entry using LDAP v2 [1] or LDAPv3 -[2], it is normally only possible to read either the attribute type, -or the attribute type and all its values. It is not possible to -selectively read just a few of the attribute values. If an attribute -holds many values, for example, the userCertificate attribute, or the -subschema publishing operational attributes objectClasses and -attributeTypes [3], then it may be desirable for the user to be able -to selectively retrieve a subset of the values, specifically, those -attribute values that match some user defined selection criteria. -Without the control specified in this [ID/standard] a client must -read all of the attribute's values and filter out the unwanted -values, necessitating the client to implement the matching rules. It -also requires the client to potentially read and process many -irrelevant values, which can be inefficient if the values are large -or complex, or there are many values stored per attribute. - -This Internet Draft specifies an LDAPv3 control to enable a user to -return only those values that matched (i.e. returned TRUE to) one or -more elements of a newly defined "values return" filter. This control -can be especially useful when used in conjunction with extensible -matching rules that match on one or more components of complex binary -attribute values. - -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 RFC 2119 [5]. - - -2. The valuesReturnFilter Control - -The valuesReturnFilter control MAY be critical or non-critical as -determined by the user. It is only applicable to the Search -operation, and SHALL be ignored by the server if it is present on any -other LDAP operation (even if marked critical on such operations). - -The object identifier for this control is 1.2.826.0.1.3344810.2.3 - - -The controlValue is - - ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem - - SimpleFilterItem ::= CHOICE { - equalityMatch [3] AttributeValueAssertion, - substrings [4] SubstringFilter, - greaterOrEqual [5] AttributeValueAssertion, - lessOrEqual [6] AttributeValueAssertion, - present [7] AttributeDescription, - approxMatch [8] AttributeValueAssertion, - extensibleMatch [9] SimpleMatchingAssertion } - - SimpleMatchingAssertion ::= SEQUENCE { - matchingRule [1] MatchingRuleId OPTIONAL, - type [2] AttributeDescription OPTIONAL, - matchValue [3] AssertionValue} - -All the above data types have their standard meanings as defined in -[2]. - -If the server supports this control, the server MUST make use of the -control as follows: - -(1) The Search Filter is first executed in order to determine -which entries satisfy the Search criteria. The control has no -impact on this step. - -(2) If the typesOnly parameter of the Search Request is TRUE, -the control has no effect and the Search Request SHOULD be -processed as if the control had not been specified. - -(3) If the attributes parameter of the Search Request consists -of a list containing only the attribute with OID "1.1" -(specifying that no attributes are to be returned), the control -has no effect and the Search Request SHOULD be processed as if -the control had not been specified. - -(4) For each attribute listed in the attributes parameter of the -Search Request, the server MUST apply the control as follows: - -i) Every attribute value that evaluates TRUE against one or -more elements of the ValuesReturnFilter is placed in the -SearchResultEntry. -ii) Every attribute value that evaluates FALSE or undefined -against all elements of the ValuesReturnFilter is not -placed in the SearchResultEntry. An attribute that has no -values selected is returned with an empty set of vals. - -Editor's Note. There is possibly a more efficient but slightly more -complex way of achieving the value filtering. An alternative is to -remove the 'present' SimpleFilterItem (which obviously evaluates true -for every attribute value of the 'present' attribute description), -and to say that any attribute whose type is not mentioned in the -ValuesReturnFilter is not filtered and has all its attribute values -returned. Comments please. - - -3. Relationship to X.500 - -The control is a superset of the matchedValuesOnly boolean of the -X.500 DAP [4] Search argument, as amended in the latest version [6]. -Close examination of the matchedValuesOnly boolean by the LDAPExt -group revealed ambiguities and complexities in the MVO boolean that -could not easily be resolved. For example, are only those attribute -values that contributed to the overall truth of the filter governed -by the MVO boolean, or all values of attributes in the filter -governed by the MVO boolean, even if the filter item containing the -attribute evaluated to false. For this reason the LDAP group decided -to replace the MVO boolean with a simple filter that removes any -uncertainty as to whether an attribute value has been selected or -not. - - -4. Examples - -(1) The first example simply shows how the control can be used to -selectively read a subset of attribute values. - -The entry below represents a groupOfNames object class containing -several members from different organizations. - -cn: Cross Organizational Standards Body -member: cn=joe,o=acme -member: cn=alice,o=acme -member: cn=bob,o=foo -member: cn=sue,o=bar - -An LDAP search operation is specified with a baseObject set to the -DN of the entry, a baseObject scope, a filter set to -"member=*o=acme", and the list of attributes to be returned set to -"member". In addition, a ValuesReturnFilter control is set to -"member=*o=acme". - -The search results returned by the server would consist of the -following entry: - -cn: Cross Organizational Standards Body -member: cn=joe, o=acme -member: cn=alice, o=acme - - -(2) The second example shows how the control can be set to match on -attributes that are (mail) and are not (telephoneNumber) part of the -search filter. It also shows how a user can filter some attribute -values (mail) and not others (telephoneNumber). - -The entries below represent inetOrgPerson [7] object classes located -below some distinguished name in the directory. - -cn: Sean Mullan -mail: sean.mullan@sun.com -mail: mullan@east.sun.com -telephoneNumber: +1 781 442 0926 -telephoneNumber: 555-9999 - -cn: David Chadwick -mail: d.w.chadwick@salford.ac.uk - -An LDAP search operation is specified with a baseObject set to the -DN of the entry, a subtree scope, a filter set to -"(|(mail=sean.mullan@sun.com)(mail=d.w.chadwick@salford.ac.uk))", and -the list of attributes to be returned set to "mail telephoneNumber". -In addition, a ValuesReturnFilter control is set to -"mail=sean.mullan@sun.com, mail=d.w.chadwick@salford.ac.uk, -telephoneNumber=*" - -The search results returned by the server would consist of the -following entries: - -cn: Sean Mullan -mail: sean.mullan@sun.com -telephoneNumber: +1 781 442 0926 -telephoneNumber: 555-9999 - -cn: David Chadwick -mail: d.w.chadwick@salford.ac.uk - -Note that the control has no effect on the values returned for the -"telephoneNumber" attribute (all of the values are returned), since -the control specified that all values should be returned. - -(3) The third example shows how one might retrieve a single attribute -type schema definition for the "gunk" attribute with OID 1.2.3.4.5 - -Assume the subschema subentry is held somewhere below the root entry -with RDN "subschema subentry", and this holds an attributeTypes -operational attribute holding the descriptions of the 35 attributes -known to this server (each description is held as a single attribute -value of the attributeTypes attribute). - -cn: subschema subentry -objectClass: subschema -attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name ) -attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE ) -attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY -objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) -attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY -generalizedTimeMatch ORDERING generalizedTimeOrderingMatch -SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER- -MODIFICATION USAGE directoryOperation ) -attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY -objectIdentifierFirstComponentMatch SYNTAX -1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) -attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch -SUBSTR caseIgnoreSubstringsMatch SYNTAX -1.3.6.1.4.1.1466.115.121.1.44{64} ) -attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY -objectIdentifierFirstComponentMatch SYNTAX -1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation ) - -plus another 28 - you get the idea. - - -The user creates an LDAP search operation with a baseObject set to -root, a subtree scope, a filter set to "objectClass=subschema", the -list of attributes to be returned set to "attributeTypes", and the -ValuesReturnFilter set to "attributeTypes=1.2.3.4.5" - -The search result returned by the server would consist of the -following entry: - -cn: subschema subentry -attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMatch -SUBSTR caseIgnoreSubstringsMatch SYNTAX -1.3.6.1.4.1.1466.115.121.1.44{64} ) - -(4) The final example shows how the control can be set to match on -attributes that are not part of the search filter. For example, -searching for all entries that have an email address in the -sun.com domain, and returning the telephone number for any attribute -values that start with "555". - -The entries below represent inetOrgPerson [7] object classes located -below some distinguished name in the directory. - -cn: Sean Mullan -mail: sean.mullan@sun.com -mail: mullan@east.sun.com -telephoneNumber: +1 781 442 0926 -telephoneNumber: 555-9999 - -cn: David Chadwick -mail: d.w.chadwick@salford.ac.uk - -An LDAP search operation is specified with a baseObject set to the -DN of the entry, a subtree scope, a filter set to "mail=*sun.com", -and the list of attributes to be returned set to "telephoneNumber". -In addition, a ValuesReturnFilter control is set to -"telephoneNumber=555*" - -The search results returned by the server would consist of the -following entry: - -cn: Sean Mullan -telephoneNumber: 555-9999 - - -5. Security Considerations - -This Internet Draft does not discuss security issues at all. - -Note that attribute values MUST only be returned if the access -controls applied by the LDAP server allow them to be returned, and in -this respect the effect of the ValuesReturnFilter control is of no -consequence. - -Note that the ValuesReturnFilter control may have a positive effect -on the deployment of public key infrastructures. Certain PKI -operations, like searching for specific certificates, become more -practical (when combined with X.509 certificate matching rules at the -server) and more scalable, since the control avoids the downloading -of potentially large numbers of irrelevant certificates which would -have to be processed and filtered locally (which in some cases is -very difficult to perform). - - -6. Acknowledgements - -The authors would like to thank members of the LDAPExt list for their -constructive comments on earlier versions of this draft, and in -particular to Harald Alvestrand who first suggested having an -attribute return filter and Bruce Greenblatt who first proposed a -syntax for this control. - -7. Copyright - -Copyright (C) The Internet Society (date). 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 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. - - -8. References - -[1] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access -Protocol", RFC 1777, March 1995. -[2] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access -Protocol (v3)", Dec. 1997, RFC 2251 -[3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory -Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec -1997 -[4] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", -1993. -[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement -Levels", RFC 2119, March 1997. -[6] ISO/IEC 9594 / ITU-T Rec X.511 (2000) The Directory: Abstract -Service Definition. -[7] M. Smith. "Definition of the inetOrgPerson LDAP Object Class", -Internet Draft , April 1999. - - -9. Authors Addresses - -David Chadwick -IS Institute -University of Salford -Salford M5 4WT -England - -Email: d.w.chadwick@salford.ac.uk - - -Sean Mullan -Sun Microsystems -East Point Business Park -Dublin 3 -Ireland -Tel: +353 1 853 0655 -Email: sean.mullan@sun.com - -Internet-Draft Returning Matched Values with LDAPv3 1 July 2000 - - -1 - diff --git a/doc/drafts/draft-ietf-ldapext-psearch-xx.txt b/doc/drafts/draft-ietf-ldapext-psearch-xx.txt deleted file mode 100644 index c313da6aaa..0000000000 --- a/doc/drafts/draft-ietf-ldapext-psearch-xx.txt +++ /dev/null @@ -1,463 +0,0 @@ - -Network Working Group M. Smith, Editor -INTERNET-DRAFT G. Good -Intended Category: Informational R. Weltman -Expires: September 2000 Netscape Communications Corp. - T. Howes - Loudcloud, Inc. - - 7 March 2000 - - - Persistent Search: A Simple LDAP Change Notification Mechanism - - - - - - -1. Status of this Memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. Internet-Drafts are working docu- -ments of the Internet Engineering Task Force (IETF), its areas, and its -working groups. Note that other groups may also distribute working -documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material -or to cite them other than as "work in progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt. - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. - -This draft document will be submitted to the RFC Editor as an Informa- -tional document. Distribution of this memo is unlimited. Technical dis- -cussion of this document will take place on the IETF LDAP Extension -Working Group mailing list . Please send -editorial comments directly to the editor . - -Copyright (C) The Internet Society (1997-2000). All Rights Reserved. - -Please see the Copyright section near the end of this document for more -information. - - - - - -Smith, et. al. Intended Category: Informational [Page 1] - -LDAP Persistent Search 7 March 2000 - - -2. Abstract - -This document defines two controls that extend the LDAPv3 [LDAP] search -operation to provide a simple mechanism by which an LDAP client can -receive notification of changes that occur in an LDAP server. The -mechanism is designed to be very flexible yet easy for clients and -servers to implement. Since the IETF is likely to pursue a different, -more comprehensive solution in this area, this document will eventually -be published with Informational status in order to document an existing -practice. - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", -"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are -to be interpreted as described in RFC 2119 [KEYWORDS]. - - - -3. General Approach - -The approach taken by the Persistent Search mechanism described in this -document is to alter the standard LDAP search operation so that it does -not end after the initial set of entries matching the search criteria -are returned. Instead, LDAP servers keep the search operation going. -This provides clients and servers participating in Persistent Search -with an active channel through which entries that change (and additional -information about the changes that occur) can be communicated. - - - -4. Persistent Search Control - -This control may be included in the Controls portion of an LDAPv3 Sear- -chRequest message. The controlType is "2.16.840.1.113730.3.4.3". - - PersistentSearch ::= SEQUENCE { - changeTypes INTEGER, - changesOnly BOOLEAN, - returnECs BOOLEAN - } - -Upon receiving this control, a server that supports it MUST process this -as a standard LDAPv3 search with the following exceptions: - - - a) If changesOnly is TRUE, the server MUST NOT return any existing - entries that match the search criteria. Entries are only - returned when they are changed (added, modified, deleted, or - subject to a modifyDN operation). - - - -Smith, et. al. Intended Category: Informational [Page 2] - -LDAP Persistent Search 7 March 2000 - - - b) The server MUST NOT return a SearchResult message. Instead, the - search operation MUST be kept active until it is abandoned by - the client or until the client unbinds. - - - c) As changes are made to the server, the effected entries MUST be - returned to the client if they match the standard search cri- - teria and if the operation that caused the change is included in - the changeTypes field. The changeTypes field is the logical OR - of one or more of these values: add (1), delete (2), modify (4), - modDN (8). - - - d) If returnECs is TRUE, the server MUST return an Entry Change - Notification control with each entry returned as the result of - changes. This control is described in the next section. - - - -5. Entry Change Notification Control - -This control provides additional information about the change the caused -a particular entry to be returned as the result of a persistent search. -The controlType is "2.16.840.1.113730.3.4.7". If the client set the -returnECs boolean to TRUE in the PersistentSearch control, servers MUST -include an EntryChangeNotification control in the Controls portion of -each SearchResultEntry that is returned due to an entry being added, -deleted, or modified. - - EntryChangeNotification ::= SEQUENCE { - changeType ENUMERATED { - add (1), - delete (2), - modify (4), - modDN (8) - }, - previousDN LDAPDN OPTIONAL, -- modifyDN ops. only - changeNumber INTEGER OPTIONAL -- if supported - } - -changeType indicates what LDAP operation caused the entry to be -returned. - -previousDN is present only for modifyDN operations and gives the DN of -the entry before it was renamed and/or moved. Servers MUST include this -optional field only when returning change notifications as a result of -modifyDN operations. - - - - -Smith, et. al. Intended Category: Informational [Page 3] - -LDAP Persistent Search 7 March 2000 - - -changeNumber is the change number [CHANGELOG] assigned by a server for -the change. If a server supports an LDAP Change Log it SHOULD include -this field. - - - -6. Intended Use - -Some of the scenarios that the Persistent Search mechanism described in -this document is designed to support are described in this section. -Other uses of the mechanism are possible as well, but please refer to -the "Implementation Considerations" section for some issues to consider. - - -6.1. Cache Consistency - -An LDAP client application with high performance needs may want to main- -tain a temporary, local cache of information obtained through LDAP -search, compare, or bind operations. To improve performance, the local -cache is always consulted before sending a request to an LDAP server. -The client application can use Persistent Search(es) against the change- -log [CHANGELOG] (if one is available) or against one or more subtrees -within the LDAP server to enable it to maintain consistency between the -data in its local cache and the data stored in the LDAP server. A Per- -sistent Search request where the changesOnly flag is FALSE can be used -if it is desirable to prime the cache; otherwise changesOnly would typi- -cally be set to TRUE in the request. - -Caches are used for reasons other than performance improvement as well. -In some cases, they arise naturally out of a particular application's -design. For example, an LDAP client designed for administration of -information held in LDAP servers will undoubtedly generate screen -displays that show information gleaned from an LDAP server. The screen -display is a cache that is active and visible until the user of the -application takes some action that causes different information to be -displayed. A refresh button or similar control may be provided to the -user to allow them to update the cached display. A Persistent Search -request can be used instead by the administrative application to -automatically refresh the screen display as soon as the underlying LDAP -information changes. - - -6.2. Synchronization - -Some LDAP clients such as those that execute on a portable computer may -maintain a partial or complete offline copy of the entries stored in an -LDAP server. While connected to the network, such a client can direct -all queries to the copy of data it holds and use a Persistent Search to - - - -Smith, et. al. Intended Category: Informational [Page 4] - -LDAP Persistent Search 7 March 2000 - - -actively maintain the contents of the offline copy (alternatively, the -client could direct requests to the LDAP server that is the source of -the data). While disconnected from the network, the client must satisfy -all queries using its offline copy of the data. When the client recon- -nects to the network, it can synchronize its own copy of the data with -the one stored on the LDAP server and proceed to actively maintain its -offline copy by issuing a Persistent Search with the changesOnly flag -set to FALSE against the server's changelog [CHANGELOG]. A search -filter like "(changeNumber>=NUM)" where NUM is an integer one greater -than the last change the client processed would be used to limit the -entries returned to the set of changes the client has not yet seen. - - -6.3. Triggered Actions - -An LDAP client application may want to take some action when an entry in -the directory is changed. A Persistent Search request can be used to -proactively monitor one or more LDAP servers for interesting changes -that in turn cause specific actions to be taken by an application. For -example, an electronic mail repository may want to perform a "create -mailbox" task when a new person entry is added to an LDAP directory and -a "delete mailbox" task when a person entry is deleted from an LDAP -directory. - - - -7. Implementation Considerations - -Implementors of servers that support the mechanism described in this -document should ensure that their implementation scales well as the -number of active Persistent Search requests increases and as the number -of changes made in the directory increases. - -Each active Persistent Search request requires that an open TCP connec- -tion be maintained between an LDAP client and an LDAP server that might -not otherwise be kept open. Therefore, client implementors are -encouraged to avoid using Persistent Search for non-essential tasks and -to close idle LDAP connections as soon as practical. Server implemen- -tors are encouraged to support a large number of client connections if -they need to support large numbers of Persistent Search clients. - - -This specification makes no guarantees about how soon a server should -send notification of a changed entry to a Persistent Search client. -This is intentional as any specific maximum delay would be impossible to -meet in a distributed directory service implementation. Server imple- -mentors are encouraged to minimize the delay before sending notifica- -tions to ensure that clients' needs for timeliness of change - - - -Smith, et. al. Intended Category: Informational [Page 5] - -LDAP Persistent Search 7 March 2000 - - -notification are met. - - - -8. Security Considerations - -In some situations, it may be important to prevent general exposure of -information about changes that occur in an LDAP server. Therefore, -servers that implement the mechanism described in this document SHOULD -provide a means to enforce access control on the entries returned and -MAY also provide specific access control mechanisms to control the use -of the PersistentSearch and EntryChangeNotification controls. - - -As with normal LDAP search requests, a malicious client can initiate a -large number of Persistent Search requests in an attempt to consume all -available server resources and deny service to legitimate clients. For -this reason, servers that implement the mechanism described in the docu- -ment SHOULD provide a means to limit the number of resources that can be -consumed by a single client. - - - -9. Copyright - -Copyright (C) The Internet Society (1997-2000). All Rights Reserved. - -This document and translations of it may be copied and furnished to oth- -ers, and derivative works that comment on or otherwise explain it or -assist in its implementation may be prepared, copied, published and dis- -tributed, 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 Stan- -dards 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 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 - - - -Smith, et. al. Intended Category: Informational [Page 6] - -LDAP Persistent Search 7 March 2000 - - -FITNESS FOR A PARTICULAR PURPOSE. - - - -10. Bibliography - -[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Require- - ment Levels", RFC 2119, March 1997. - -[LDAP] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - -[CHANGELOG] G. Good, "Definition of an Object Class to Hold LDAP Change - Record", INTERNET-DRAFT , - July 1997. - -[PSEARCHAPI] M. Smith, "LDAP C API Extensions for Persistent Search", - INTERNET-DRAFT , - March 1998. - - - -11. Authors' Addresses - - Mark Smith - Netscape Communications Corp. - 501 E. Middlefield Rd., Mailstop MV068 - Mountain View, CA 94043 - USA - +1 650 937-3477 - mcs@netscape.com - - Gordon Good - Netscape Communications Corp. - 501 E. Middlefield Rd., Mailstop MV068 - Mountain View, CA 94043 - USA - +1 650 937-3825 - ggood@netscape.com - - Rob Weltman - Netscape Communications Corp. - 501 E. Middlefield Rd., Mailstop MV068 - Mountain View, CA 94043 - USA - +1 650 937-3301 - rweltman@netscape.com - - - - -Smith, et. al. Intended Category: Informational [Page 7] - -LDAP Persistent Search 7 March 2000 - - - Tim Howes - Loudcloud, Inc. - 615 Tasman Dr. - Sunnyvale, CA 94089 - USA - +1 650 321 4565 - howes@loudcloud.com - - - -12. Appendix A: Changes since draft-ietf-ldapext-psearch-01.txt - - "Status of this Memo" section: changed "Intended Category" to Infor- - mational. Also updated boilerplate text to reflect current I-D - guidelines and updated copyright to include the year "2000." - - "Abstract" section: added sentence that says why this will be pub- - lished as Informational. - - "Entry Change Notification Control" section: added the word "only" to - clarify that the previousDN field is only returned for modifyDN - operations. - - "Authors' Addresses" section: updated Tim Howes' information. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Smith, et. al. Intended Category: Informational [Page 8] - - - -1. Status of this Memo............................................1 -2. Abstract.......................................................2 -3. General Approach...............................................2 -4. Persistent Search Control......................................2 -5. Entry Change Notification Control..............................3 -6. Intended Use...................................................4 -6.1. Cache Consistency...........................................4 -6.2. Synchronization.............................................4 -6.3. Triggered Actions...........................................5 -7. Implementation Considerations..................................5 -8. Security Considerations........................................6 -9. Copyright......................................................6 -10. Bibliography...................................................7 -11. Authors' Addresses.............................................7 -12. Appendix A: Changes since draft-ietf-ldapext-psearch-01.txt...8 diff --git a/doc/drafts/draft-ietf-ldapext-refer-xx.txt b/doc/drafts/draft-ietf-ldapext-refer-xx.txt deleted file mode 100644 index 184e801efb..0000000000 --- a/doc/drafts/draft-ietf-ldapext-refer-xx.txt +++ /dev/null @@ -1,728 +0,0 @@ -IETF LDAPEXT Working Group Roland Hedberg -Internet-Draft Catalogix -Expires: January 12, 2000 July 12, 2000 - - - - - - Referrals in LDAP Directories - - - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as - Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - This Internet-Draft will expire on January 12, 2000. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - - - - - - - - - - - -Hedberg Expires September 30, 2000 [Page 1] - -Internet-Draft LDAP Knowledge references July 2000 - -Abstract - - This document defines two reference attributes and associated "referral" - object class for representing generic knowledge information in LDAP - directories [RFC2251]. - The attribute uses URIs [RFC1738] to represent knowledge, - enabling LDAP and non-LDAP services alike to be referenced. - The object class can be used to construct entries in an LDAP directory - containing references to other directories or services. This document - also defines procedures directory servers should follow when supporting - these schema elements and when responding to requests for which the - directory server does not contain the requested object but may contain - some knowledge of the location of the requested object. - - -1. Background and intended usage - - The broadening of interest in LDAP directories beyond their use as front - ends to X.500 directories has created a need to represent knowledge - information in a more general way. Knowledge information is information - about one or more servers maintained in another server, used to link - servers and services together. - - This document is based on the following basic assumptions: - - - several naming domains - The usage of LDAP as a access protocol to other than X.500 servers has - created islands of directory service systems containing one or more - LDAP servers. Each of these islands are free to pick their own naming - domain. And that they also do; some use the old country,organization, - organizationalUnit naming scheme[X.521], some use the newer domain name - based naming scheme but these two are in no way the only ones in use. The - existence of several naming domains are in itself no real problem as - long as they produce unique names for the objects in the directory. - Still naming schemes like the domain name based one, might easily create - non-continues naming structures because some toplevel domain names - might no find organizations that are interested and/or willing - to manage them. Therefor tree transversal might not longer be possible - except in parts of the whole tree. - - - authoritive structure vs directory structure - In some instances even if a part of the tree is delegated to one - organization, the organization doing the delegation might want to - remain as the authority for the baseobject of the delegated tree. - - - support for onelevel searches - At points in the tree where the responsibility for all or almost all - of the children of a object is delegated to different organizations - and resides in different directory servers a one-level search is not - very efficient if not supported by special facilities in the directory - as such. - -Hedberg Expires September 30, 2000 [Page 2] - -Internet-Draft LDAP Knowledge references July 2000 - - -- directory server discovery - LDAP servers that do not use dc nameing or are not registered with - SRV records in the DNS are very hard to find. - - This document defines a general method of representing knowledge - information in LDAP directories, based on URIs. - Two types of knowledge reference are defined: refer and subRefer. - - The key words "MUST", "SHOULD", and "MAY" used in this document are to - be interpreted as described in [RFC2119]. - -2. Knowledge references - -2.1 The refer attribute - - ( 1.2.752.17.1.100 - NAME 'refer' - DESC 'URL reference' - EQUALITY caseExactIA5Match - SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 - USAGE distributedOperation ) - - The refer attribute type has IA5 syntax and is case sensitive. - It is multivalued. Values placed in the attribute MUST conform to the - specification given for the labeledURI attribute as defined in [RFC2079]. - - The labeledURI specification defines a format that is a URI, - optionally followed by whitespace and a label. This document does not - make use of the label portion of the syntax. Future documents MAY enable - new functionality by imposing additional structure on the label portion - of the syntax as it appears in a refer attribute. - If the URI contained in a refer attribute refers to an LDAP - server, it must be in the LDAP URI format described in [RFC2255]. - - When returning a referral result, the server must not return the label - portion of the labeledURI as part of the referral. Only the URI portion - of the refer attributes should be returned. - - The refer attribute can be further specified by the use of options as - defined in section 4.1.5 of [RFC2251]. This document defines five - options and their use. Future documents might defined other options. - - The options defined are: - "me", "sup", "cross", "nssr" and "sub" . - - 'refer;me' is used to hold the reference of this server, and is always - held in the root DSE - - 'refer;sup' is used to hold the reference of a server superior to this - one in this global LDAP naming domain e.g. a server holding the dc=com, - dc=se, or the c=se node. The 'refer;sup' is always held in the root DSE. - -Hedberg Expires September 30, 2000 [Page 3] - -Internet-Draft LDAP Knowledge references July 2000 - - 'refer;cross' indicates that this is a cross reference pointing to another - naming context within or outside this global LDAP naming domain. - - 'refer;sub' indicates that this is a subordinate reference pointing to - a subordinate naming context in this global LDAP naming domain. - - 'refer;nssr' indicates that this is a non-specific subordinate reference - pointing to a subordinate naming context in this global LDAP naming domain. - - -3. Use of the knowledge attribute - - Except when the manageDsaIT control (documented in section 6 of this - document) is present in the operation request, the refer attribute is not - visible to clients, except as its value is returned in referrals or con- - tinuation references. - - If the manageDsaIT control is not set, and the entry named in a request - contains the refer attribute, and the entry is not the root DSE, the - server returns an LDAPResult with the resultCode field set to "referral" - and the referral field set to contain the value(s) of the refer attribute - minus any optional trailing whitespace and labels that might be present. - - If the manageDsaIT control is not set, and an entry containing the ref - attribute is in the scope of a one level or subtree search request, the - server returns a SearchResultReference for each such entry containing - the value(s) of the entry's refer attribute. - - When the manageDsaIT control is present in a request, the server will - treat an entry containing the refer attribute as an ordinary entry, and - the refer attribute as an ordinary attribute, and the server will not - return referrals or continuation references corresponding to refer - attributes. - - -4 Behaviour specification - -4.1 Name resolution for any operation - - Clients SHOULD perform at least simple "depth-of-referral count" loop - detection by incrementing a counter each time a new set of referrals is - received. (The maximum value for this count SHOULD be twice the number - of RDNs in the target object less one, to allow for ascending and - descending the DIT.) Clients MAY perform more sophisticated loop - detection, for example not chasing the same referral twice. - - Case 1: The target entry is not held by the server and is - superior to some entry held by the server. - - If the server DSE contains a "refer;sup" attribute then - the server will return an LDAPResult with the result code field set - -Hedberg Expires September 30, 2000 [Page 4] - -Internet-Draft LDAP Knowledge references July 2000 - - to referral, and the referral field set to contain the value(s) of - the "refer;sup" attribute minus any optional trailing whitespace and - labels that might be present. - - Case 2: The target entry is not held by the server and is - subordinate to some entry, held by the server, that contains a - refer attribute. - - The server will return an LDAPResult with the result code field set - to referral, and the referral field set to contain the value(s) of - the refer attribute minus any optional trailing whitespace and labels - that might be present. - - Case 3: The target entry is held by the server and contains a - refer attribute without the 'nssr' option. - - The server will return an LDAPResult with the result code field set - to referral, and the referral field set to contain the value(s) of - the refer attribute minus any optional trailing whitespace and labels - that might be present. - - Case 4: The target entry is not held by the server, and is not - subordinate or superior to any object held by the server. - - If the server contains a "refer;cross" attribute - in the root DSE with a baseobject that is either the same or - superior to the target entry then - the server will return an LDAPResult with the result code field set - to referral, and the referral field set to contain the value(s) of - these refer attributes minus any optional trailing whitespace and labels - that might be present. - - -4.2 Search evaluation - - For search operations, once the base object has been found and - determined NOT to contain a refer attribute without the 'nssr' - option, the search may progress. - -4.2.1 base-level - - If the entry matches the filter and does NOT contain a refer attribute - it will be returned to the client as described in [RFC2251]. - If the entry matches the filter contains a refer attribute without - the 'nssr' option it will be returned as a referral as described here. - - If a matching entry contains a refer attribute and the URI - contained in the refer attribute is NOT an LDAP URI [RFC2255], - the server should return the URI value contained in the refer - attribute of that entry in a SearchResultReference. - - -Hedberg Expires September 30, 2000 [Page 5] - -Internet-Draft LDAP Knowledge references July 2000 - - - If a matching entry contains a refer attribute in the LDAP - URI syntax, the server will return an SearchResultReference - containing the value(s) of the refer attribute minus any optional - trailing whitespace and labels that might be present. - The URL from the refer attribute must be modified before it is - returned by adding or substituting a "base" scope into the URL. If the - URL does not contain a scope specifier, the "base" scope specifier must - be added. If the URL does contain a scope specifier, the existing scope - specifier must be replaced by the "base" scope. - -4.2.2 One-level - - Any entries matching the filter and one level scope that - do NOT contain a refer attribute are returned to the client normally as - described in [RFC2251]. Any entries matching the filter and one level - scope that contains a refer attribute without the 'nssr' option must - be returned as referrals as described here. - - If a matching entry contains a refer attribute and the URI - contained in the refer attribute is NOT an LDAP URI [RFC2255], - the server should return the URI value contained in the refer - attribute of that entry in a SearchResultReference. - - If a matching entry contains a refer attribute in the LDAP - URI syntax, the server will return an SearchResultReference - containing the value(s) of the refer attribute minus any optional - trailing whitespace and labels that might be present. - The URL from the refer attribute must be modified before it is - returned by adding or substituting a "base" scope into the URL. If the - URL does not contain a scope specifier, the "base" scope specifier must - be added. If the URL does contain a scope specifier, the existing scope - specifier must be replaced by the "base" scope. - -4.2.3 Subtree search evaluation - - Any entries, held by the server, matching the filter and - subtree scope that do NOT contain a refer attribute or contains - a refer attribute with the 'nssr' option are - returned to the client normally as described in [RFC2251]. - Any entries matching the subtree scope and containing a refer - attribute must be returned as referrals as described here. - - If a matching entry contains a refer attribute and the URI - contained in that attribute is NOT an LDAP URI [RFC2255], - the server should return the URI value contained in the refer - attribute of that entry in a SearchResultReference. - - - - - -Hedberg Expires September 30, 2000 [Page 6] - -Internet-Draft LDAP Knowledge references July 2000 - - If a matching entry contains a refer attribute in the LDAP - URI syntax, the server will return an SearchResultReference - containing the value(s) of the refer attribute minus any - optional trailing whitespace and labels that might be present. - - N.B. in subtree search evaluation a entry containing a - refer attribut with the 'nssr' option might appear twice in the - result, first as a entry and then as a reference. A client - following all references might therefore end up with a resultset - containing two representations of the same entry, one from the - server getting the original query and one from the server - that the 'nssr' reference points to. - - -5. The referral object class - - The referral object class is defined as follows. - - ( 1.2.752.17.2.10 - NAME 'referral' - SUP top - STRUCTURAL - MAY ( refer ) ) - - The referral object class is a subclass of top and may contain the - refer attribute. The referral object class should, in general, - be used in conjunction with the extensibleObject object class to support - the naming attributes used in the entry's distinguished name. - - Servers must support the refer attributes through use of the - referral object class. Any named reference must be of the referral - object class and will likely also be of the extensibleObject object - class to support naming and use of other attributes. - - -6. The manageDsaIT control - - A client MAY specify the following control when issuing a search, com- - pare, add, delete, modify, or modifyDN request. - - The control type is 2.16.840.1.113730.3.4.2. The control SHOULD be - marked as critical. There is no value; the controlValue field is - absent. - - This control causes entries with the knowledge reference attributes to be - treated as normal entries, allowing clients to read and modify these entries. - - - - - - -Hedberg Expires September 30, 2000 [Page 7] - -Internet-Draft LDAP Knowledge references July 2000 - - -7. Superior Reference - - This document defines two types of knowledge references that point to - parts of the naming context that is above of beyone the part held by a server. - The 'sup' option when referring to a LDAP server that holds a - naming context that is closer to the root of the same naming context and - 'other' when referring to a LDAP server that holds a naming - context that belongs to a different naming domain then the one the - server belongs to. - - Thus if the server receives a request for an operation where the - target entry is a entry closer to the root than the naming - context held the server and if the server holds a 'refer;sup' attribute - in the DSE, then the server MUST return an LDAPResult with the result - code field set to referral, and the referral field set to contain the - value(s) of the 'refer;sub' attribute minus any optional trailing - whitespace and labels that might be present. - - On the other hand if the server receives a request for an operation - where the target entry is a entry that belongs to a other naming domain - and if there is any 'refer;other' attributes in the DSE with a base entry - that belongs to the same naming domain as the target entry and is - closer to the root then the target entry, then the server SHOULD return - an LDAPResult with the result code field set to referral, and the referral - field set to contain the value(s) of the 'refer;other' attribute minus - any optional trailing hitespace and labels that might be present. - - -8. Security Considerations - - This document defines mechanisms that can be used to "glue" LDAP (and - other) servers together. The information used to specify this glue - information should be protected from unauthorized modification. If the - server topology information itself is not public information, the - information should be protected from unauthorized access as well. - - -9. References - - [RFC1738] - Berners-Lee, T., Masinter, L., and McCahill, M., "Uniform Resource - Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of - Minnesota, December 1994, - - [RFC2079] - M. Smith, "Definition of an X.500 Attribute Type and an Object Class - to Hold Uniform Resource Identifiers (URIs)", RFC 2079, January - 1997. - - - -Hedberg Expires September 30, 2000 [Page 8] - -Internet-Draft LDAP Knowledge references July 2000 - - - [RFC2119] - S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- - els", RFC 2119, March 1997. (Format: TXT=4723 bytes) (Also BCP0014) - (Status: BEST CURRENT PRACTICE) - - [RFC2251] - M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol - (v3)", RFC 2251, December 1997. 1997. - - [RFC2255] - T. Howes, M. Smith, "The LDAP URL Format", RFC 2255, December, 1997. - (Format: TXT=20685 bytes) (Status: PROPOSED STANDARD) - - [X500] - ITU-T Rec. X.501, "The Directory: Models", 1993. - - [X521] - ITU-T Rec. X.521, "---------------------", 1993. - - -12. Acknowledgements - - This draft is heavily based on the previous drafts on knowledge - references in LDAP written by Christopher Lukas, Tim Howes, - Michael Roszkowski, Mark C. Smith, Mark Wahl and David Chadwick. - Peter Valkenburg and Henny Bekker has also made valueable - contributions. - - -13. Authors Address - - Roland Hedberg - Catalogix - Dalsveien 53 - 0775 Oslo - Norway - EMail: Roland@catalogix.se - - - - - - - - - - - - - - -Hedberg Expires September 30, 2000 [Page 9] - -Internet-Draft LDAP Knowledge references July 2000 - - - Appendix A - - Example of usage. - Information stored in a server. - - dn: - objectclass: referral - refer;me: ldap://hostCAT/dc=cat,dc=se - refer;sup: ldap://hostSE/dc=se - refer;cross: ldap://hostNO/dc=no - refer;cross: ldap://hostNL/c=nl - - dn: dc=cat,dc=se - objectclass: domain - dc: cat - - dn: dc=one,dc=cat,dc=se - objectclass: extendedObject - objectclass: referral - refer;nssr: ldap://hostCAT1/dc=one,dc=cat,dc=se - ou: one - l: umea - - dc: dc=two,dc=cat,dc=se - objectclass: referral - objectclass: extendedObject - refer;sub: ldap://hostCAT2/dc=two,dc=cat,dc=se - - dn: dc=three,dc=cat,dc=se - objectclass: referral - objectclass: extendedObject - refer;cross: ldap://hostCAT3/dc=cat,dc=nl - - dc: dc=four,dc=cat,dc=se - objectclass: domain - objectclass: extendedObject - ou: four - l: umea - - - - - - - - - - - - - -Hedberg Expires September 30, 2000 [Page 10] - -Internet-Draft LDAP Knowledge references July 2000 - - - ========================================== - A number of descriptive cases - ========================================== - - case 1: One-level search, target object on the server - search - baseobject: dc=cat,dc=se - scope: onelevel - filter: (objectclass=*) - attributes: ou - - returns - searchResultEntry { - dn: dc=one,dc=cat,dc=se - ou: one - } - searchResultReference { - ldapurl: ldap://hostCAT2/dc=two,dc=cat,dc=se - } - searchResultReference { - ldapurl: ldap://hostCAT3/dc=cat,dc=nl - } - searchResultEntry { - dn: dc=four,dc=cat,dc=se - ou: four - } - searchResultDone { - resultCode: success - } - - case 2: Subtree search, target object on the server - search - baseobject: dc=cat,dc=se - scope: subtree - filter: (objectclass=*) - attributes: ou - - returns - searchResultEntry { - dn: dc=one,dc=cat,dc=se - ou: one - } - searchResultReference { - ldapurl: ldap://hostCAT1/dc=one,dc=cat,dc=se - } - searchResultReference { - ldapurl: ldap://hostCAT2/dc=two,dc=cat,dc=se - } - - - -Hedberg Expires September 30, 2000 [Page 11] - -Internet-Draft LDAP Knowledge references July 2000 - - - searchResultReference { - ldapurl: ldap://hostCAT3/dc=cat,dc=nl - } - searchResultEntry { - dn: dc=four,dc=cat,dc=se - ou: four - } - searchResultDone { - resultCode: success - } - - case 3: base search, target entry contains a 'refer;nssr' attribute - search - baseobject: dc=one,dc=cat,dc=se - scope: base - filter: (objectclass=*) - attributes: ou - - returns - searchResultEntry { - dn: dc=one,dc=cat,dc=se - ou: four - } - searchResultDone { - resultCode: success - } - - case 4: base search, target entry contains a 'refer;sub' attribute - search - baseobject: dc=two,dc=cat,dc=se - scope: base - filter: (objectclass=*) - attributes: ou - - returns - searchResultDone { - resultCode: referral - matchedDN: dc=two,dc=cat,dc=se - referral: ldap://hostCAT2/dc=two,dc=cat,dc=se - } - - - - - - - - - - - -Hedberg Expires September 30, 2000 [Page 12] - -Internet-Draft LDAP Knowledge references July 2000 - - - case 5: one-level search, target entry contains a 'refer;nssr' attribute - search - baseobject: dc=one,dc=cat,dc=se - scope: onelevel - filter: (objectclass=*) - attributes: ou - - searchResultDone { - resultCode: referral - matchedDN: dc=one,dc=cat,dc=se - referral: ldap://hostCAT1/dc=one,dc=cat,dc=nu - } - - case 6: Search on area above the baseobject of the server - search - baseobject: dc=pi,dc=se - scope: subtree - filter: (objectclass=*) - attributes: ou - - returns - searchResultDone { - resultCode: referral - matchedDN: dc=se - referral: ldap://hostSE/dc=se - } - - - - case 7: Search on area beyond, but not below the baseobject - of the server - search - baseobject: o=surfnet,c=nl - scope: base - filter: (objectclass=*) - - returns - searchResultDone { - resultCode: referral - matchedDN: c=nl - referral: ldap://hostNL/c=NL - } - - - - - - - - - -Hedberg Expires September 30, 2000 [Page 13] - diff --git a/doc/drafts/draft-ietf-ldup-framing-xx.txt b/doc/drafts/draft-ietf-ldup-framing-xx.txt deleted file mode 100644 index 404e8ac603..0000000000 --- a/doc/drafts/draft-ietf-ldup-framing-xx.txt +++ /dev/null @@ -1,340 +0,0 @@ - -Extended Operations for Framing LDAP Operations -Internet-Draft -Intended Category: Standards Track -Expires: September 10, 2000 - - - Ellen Stokes - IBM Corporation - - Roger Harrison - Novell, Inc. - - Gordon Good - Netscape Communications Corp. - - March 10, 2000 - - Extended Operations for Framing LDAP Operations - Filename: draft-ietf-ldup-framing-00.txt - -Table of Contents - -1. Status of this Memo.............................................2 -2. Abstract........................................................2 -3. Overview........................................................2 -4. Protocol element definitions....................................3 -4.1 StartFramedProtocolRequest Extended Operation...................3 -4.2 StartFramedProtocolResponse Extended Operation..................3 -4.3 EndFramedProtocolRequest Extended Operation.....................4 -4.4 EndFramedProtocolResponse Extended Operation....................4 -5. Acknowledgments.................................................5 -6. References......................................................5 -7. Author's Addresses..............................................5 - - - - - - - - - - - - - - - - - - - - -Stokes, Harrison and Good [Page 1] - -Internet-Draft LDUP Workgroup March 10, 2000 - - -1. Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that other - groups may also distribute working documents as Internet-Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet- Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - -. - - This Internet Draft expires September 10, 2000. - - -2. Abstract - - Certain types of LDAP applications can benefit from the ability to - specify the beginning and end of a related group of operations. For - example, the LDUP multimaster update protocol [ARCHITECTURE] requires - that two servers agree to begin a session to transfer pending - replication updates. This document provides a framework for - constructing protocols that feature a framed set of related - operations. It defines a pair of LDAPv3 extended operations that - provide begin-end framing, and a pair of extended operations used to - respond the begin-end framing operations. The nature of the actual - LDAP operations carried inside these framing operations is not - specified in this document. - - All protocol elements described here are LDAP Version 3 extended - operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. - - Certain terms used in this document are defined in the document "LDAP - Replication Architecture" [ARCHITECTURE]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are - to be interpreted as described in RFC 2119 [KEYWORDS]. - -3. Overview - - This document describes two LDAPv3 Extended Operations that are used - to signal the beginning and end of a set of grouped operations, and - - - -Stokes, Harrison and Good [Page 2] - -Internet-Draft LDUP Workgroup March 10, 2000 - - - two LDAPv3 extended operations that are used to respond to these - operations. These extended operations provide a framework that may be - used when developing a protocol that requires begin-end framing. - -4. Protocol element definitions - -4.1 StartFramedProtocolRequest Extended Operation - - The StartFramedProtocolRequest extended operation indicates that the - initiator wishes to begin transmission of a set of related LDAP - operations. The requestValue of the StartFramedProtocolRequest - extended operation contains an OID that describes the specific framed - protocol being initiated, and a protocol-specific payload. - - An LDAPv3 Extended Request is defined in [LDAPv3] as follows: - - ExtendedRequest ::= [APPLICATION 23] SEQUENCE { - requestName [0] LDAPOID, - requestValue [1] OCTET STRING OPTIONAL - } - - The requestName portion of the StartFramedProtocolRequest must be the - OID "2.16.840.1.113719.1.142.100.1". - - The requestValue of the StartFramedProtocolRequest must be set to the - BER-encoding of the following: - - StartFramedProtocolRequestValue ::= SEQUENCE { - framedProtocolOID LDAPOID, - framedProtocolPayload OPTIONAL OCTET STRING - } - - The parameters in the requestValue of the StartFramedProtocolRequest - are: - - - framedProtocolOID: An OID that uniquely identifies the protocol - framed by this operation. - framedProtocolPayload: An octet - string that contains protocol-specific - information. - - -4.2 StartFramedProtocolResponse Extended Operation - - The StartFramedProtocolResponse extended operation is sent in - response to a StartFramedProtocolResponse extended operation. - - An LDAPv3 Extended Response is defined in [LDAPv3] as follows: - - - - -Stokes, Harrison and Good [Page 3] - -Internet-Draft LDUP Workgroup March 10, 2000 - - - ExtendedResponse ::= [APPLICATION 24] SEQUENCE { - COMPONENTS of LDAPResult, - responseName [10] LDAPOID OPTIONAL, - response [11] OCTET STRING OPTIONAL - } - - The responseName of the StartFramedProtocolResponse must be the OID - "2.16.840.1.113719.1.142.100.2". - - The response of the StartFramedProtocolResponse is set to the BER- - encoding of a protocol-specific response. - -4.3 EndFramedProtocolRequest Extended Operation - - The EndFramedProtocolRequest extended operation indicates the end a - set of related LDAP operations. The requestValue of the - EndFramedProtocolRequest extended operation contains a protocol- - specific payload. - - An LDAPv3 Extended Request is defined in [LDAPv3] as follows: - - ExtendedRequest ::= [APPLICATION 23] SEQUENCE { - requestName [0] LDAPOID, - requestValue [1] OCTET STRING OPTIONAL - } - - The requestName of the EndFramedProtocolRequest must be the OID - "2.16.840.1.113719.1.142.100.4". - - The requestValue of the EndFramedProtocolRequest is set to the BER- - encoding of a protocol-specific response. - -4.4 EndFramedProtocolResponse Extended Operation - - The EndFramedProtocolResponse extended operation is sent in response - to an EndFramedProtocolRequest. - - An LDAPv3 Extended Response is defined in [LDAPv3] as follows: - - ExtendedResponse ::= [APPLICATION 24] SEQUENCE { - COMPONENTS of LDAPResult, - responseName [10] LDAPOID OPTIONAL, - response [11] OCTET STRING OPTIONAL - } - - The responseName of the EndFramedProtocolResponse must be the OID - "2.16.840.1.113719.1.142.100.5". - - - - -Stokes, Harrison and Good [Page 4] - -Internet-Draft LDUP Workgroup March 10, 2000 - - - The response of the EndFramedProtocolResponse is set to the BER- - encoding of a protocol-specific response. - -5. Acknowledgments - -The authors gratefully acknowledge the contributions of the IETF LDUP -working group. - -6. References - - -[KEYWORDS] - S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- - els", Harvard University, RFC 2119, March 1997. - - -[ARCHITECTURE] - J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec- - ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999. - - -[LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol - (v3)", RFC 2251, December 1997. - -7. Author's Addresses - - Ellen Stokes - IBM - 11400 Burnet Rd - Austin, TX 78758 - USA - EMail: stokes@austin.ibm.com - phone: +1 512 838 3725 - fax: +1 512 838 0156 - - Roger Harrison - Novell, Inc. - 122 E. 1700 S. - Provo, UT 84606 - USA - EMail: roger_harrison@novell.com - Phone: +1 801 861 2642 - - Gordon Good - Netscape Communications Corp. - 501 E. Middlefield Rd. - Mailstop MV068 - - - -Stokes, Harrison and Good [Page 5] - -Internet-Draft LDUP Workgroup March 10, 2000 - - - Mountain View, CA 94043 - USA - EMail: ggood@netscape.com - Phone: +1 650 937-3825 - - -Appendix A - Complete ASN.1 Definition - -StartFramedProtocolRequest ::= ExtendedRequest - -StartFramedProtocolRequestValue ::= SEQUENCE { - framedProtocolOID LDAPOID, - framedProtocolPayload OPTIONAL OCTET STRING -} - -StartFramedProtocolResponse ::= ExtendedResponse - -EndFramedProtocolRequest ::= ExtendedRequest - -EndFramedProtocolResponse ::= ExtendedResponse - -Full Copyright Statement - -Copyright (C) The Internet Society (1999). All Rights Reserved. - -This document and translations of it may be copied and furnished to oth- -ers, and derivative works that comment on or otherwise explain it or -assist in its implementation may be prepared, copied, published and dis- -tributed, 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 Stan- -dards 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 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 FIT- -NESS FOR A PARTICULAR PURPOSE. - - - - -Stokes, Harrison and Good [Page 6] diff --git a/doc/drafts/draft-ietf-ldup-infomod-xx.txt b/doc/drafts/draft-ietf-ldup-infomod-xx.txt deleted file mode 100644 index b1e5ab1aac..0000000000 --- a/doc/drafts/draft-ietf-ldup-infomod-xx.txt +++ /dev/null @@ -1,1021 +0,0 @@ -INTERNET-DRAFT -draft-ietf-ldup-infomod-01.txt - Ed Reed - Reed-Matthews, Inc. - March 9, 2000 - - LDUP Replication Information Model - - -1. Status of this Memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet Engineering Task -Force (IETF), its areas, and its working groups. Note that other -groups may also distribute working documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of six months -and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet-Drafts as reference material -or to cite them other than as "work in progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt. - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. - -This Internet-Draft expires on May 11, 1999. - - -2. Abstract - -[LDUP Model] describes the architectural approach to replication of -LDAP directory contents. This document describes the information -model and schema elements which support LDAP Replication Services -which conform to [LDUP Model]. - -Directory schema is extended to provide object classes, subentries, -and attributes to describe areas of the namespace which are under -common administrative authority, units of replication (ie, subtrees, -or partitions of the namespace, which are replicated), servers which -hold replicas of various types for the various partitions of the -namespace, which namespaces are held on given servers, and the -progress of various namespace management and replication operations. -Among other things, this knowledge of where directory content is - - - -Reed [Page 1] - Expires September 9, 2000 - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -located will provide the basis for dynamic generation of LDAP -referrals for clients who can follow them. - -The controlling framework by which the relationships, types, and -health of replicas of the directory content will be defined so that, -as much as possible, directory content is itself used to monitor and -control the environment. - -Security information, including access control policy identifiers and -information will be treated as directory content by the replication -protocols when specified by the LDAPEXT group. - -The information model will describe required and optional house- -keeping duties for compliant systems to implement, such as garbage -collection of deleted objects, reconciliation of moved and renamed -objects, update sequencing and transaction bracketing of changes, etc. - -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 RFC 2119 [RFC2119]. The -sections below reiterate these definitions and include some additional -ones. - - -2.1 Changes in this version - -LDAP Subentry definition is moved to its own document [SUBENTRY]. - -LDAP Schedule Subentry definition is defined. - -LDAP Access Point removed in favor of just using the DN of the server -holding the replica (so a new syntax isn't required). - -LDAP Change Sequence Number syntax eleminated in favor of just calling -it a CaseIgnoreString, so new comparison rules aren't required. - -Deleted ldapSearchFilter definition from here. Sparse replicas is -deferred. Might sparse be supported for single-master configurations -(read-only, of course). - -Fractional are okay in multi-master configurations, but again, only on -read-only replicas. - -Changed the naming convention upper-lower case usage to look less -weird. - -Note: - - -Reed [Page 2] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -Consistency discussion - -Schema document must clearly indicate that clients can and should -inspect the replica subentries to understand the single-master/multi- -master nature of the naming context to which they're talking. - -The paradigm change, to distributed data, needs to be exhaustively -discussed in the profile documents. How old applications which assume -single-master behave or misbehave in a multi-master environment is -critical to make clear. Draw examples from SMP pre-emptive -programming practices, from DNS vs host file models, etc. - - - -Decisions from wash ietf_ - -1) define two simple schema classes _ event driven histeresis - buckets, and cron-like thing. Then, the replica has a single - value pointer to a schedule. More schedule things can be - defined in the future. - -2) Create attribute ReplicaURI to provide service access point for - that replica. No DSA entry requirement. - -3) Replica id table discussion should move to protocol spec. - -To do: -1) define the cron schedule subentry class -2) define the rest of the attributes used in the classes -3) verify LDUP OID number with Novell (!) one more time -4) verify all OIDs assigned -5) verify all OIDs documented at the end of the document -6) scrub editorial comments -7) cross reference with arch document on schema element names - - - - - - - - - - - - - - - -Reed [Page 3] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -Table of Contents -1. Status of this Memo .............................................1 -2. Abstract 1 -2.1 Changes in this version........................................2 -3. Introduction ....................................................4 -3.1 Scope 4 -3.2 Terms and Definitions..........................................5 -4. Data design: ....................................................5 -5. Directory Knowledge .............................................5 -6. Schema 6 -6.1 Data Structure Definitions.....................................6 -6.1.1 ldapChangeSequenceNumber..................................6 -6.2 Attribute Definitions..........................................7 -6.2.1 attributeExclusionFilter..................................7 -6.2.2 attributeInclusionFilter..................................8 -6.2.3 replicaURI................................................8 -6.2.4 replicationStatus.........................................9 -6.2.5 replicaType...............................................9 -6.2.6 SecsToWait Attributes....................................11 -6.2.6.1 secsToWaitCat1 ........................................11 -6.2.6.2 secsToWaitCat2 ........................................11 -6.2.6.3 secsToWaitCat3 ........................................11 -6.2.6.4 secsToWaitCat4 ........................................11 -6.2.6.5 secsToWaitCat5 ........................................11 -6.2.7 updateVector.............................................12 -6.3 Class Definitions.............................................12 -6.3.1 nameContext..............................................12 -6.3.2 replicaSubentry..........................................12 -6.3.3 replicaAgreementSubentry.................................13 -6.3.4 eventScheduledSubentry Class.............................14 -6.3.5 timeScheduledSubentry Class..............................15 -7. Object Identifier Assignments ..................................15 -8. Security Considerations ........................................16 -9. References .....................................................16 -10. Copyright Notice ...............................................17 -11. Acknowledgements ...............................................17 -12. Author's Address ...............................................18 - - -3. Introduction - - -3.1 Scope - -This document describes schema of subentries representing replicas, -replication agreements and their dependencies. - - - -Reed [Page 4] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -Management and status schema elements may be defined if there is -sufficient consensus. - -Semantic interpretation of schema elements, including any special -handling expectations are to be provided here. - - -3.2 Terms and Definitions - -Definitions are provided in [LDUP Requirements], and may be reproduced -here for the convenience of the reader. - - - -4. Data design: - -As described in [LDUP Model], knowledge of replicated portions of the -directory information tree (DIT) is stored in the directory itself. - -An auxiliary class is defined to designate containers, or nodes, in -the DIT which are the root-most, or base, of naming contexts -[RFC2251]. Directory subentries [X501] are used to hold information -about replicas and replica agreements. - - - -5. Directory Knowledge - -Information about what replicas exist, what they contain, their types, -where they are stored, and how they may be contacted inevitably -provides the basis for distributed directory knowledge. As namespaces -from stand-alone servers are inter-connected with one another, this -replica information can and will be used by name resolution operations -to locate servers holding copies of specific objects, and to optimize -distributed searches which span multiple Naming Contexts. - -However, the focus of this document is NOT to fully enable such -distributed directory uses. Instead, we are focused on how portions -of the namespace (Directory Information Tree - DIT) may be replicated, -and how those replicas are configured and related to one another via -Replication Agreements. - -As such, the following high level description (from [LDUP Model])of -the information model envisioned is provided as reference for the -reader before presenting the detailed specifications. - -Generally, the DSE Naming Context attribute of an LDAPv3 server names -the Naming Contexts for which there are replicas on that server. - -Reed [Page 5] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -The Naming Context Auxiliary Class (nameContext) is added to container -objects which may have separately defined replication policy. - -Immediately subordinate to a Naming Context object are the Replica -Subentry containers which identify where the identified replica -resides (ie, its LDAP Access Point), its type (Primary, Updateable, -ReadOnly), if it is sparse, the LDAP search filter which defines what -object classes it holds, and if it is fractional, the attributes it -does or does not hold. - -Immediately subordinate in the namespace to a Replica Subentry are -Replication Agreement leaf entries which each identify another -Replica, the scheduling policy for replication operations (including -times when replication is to be performed, when it is not to be -performed, or the policies governing event-driven replication -initiation). - - - -6. Schema - - -6.1 Data Structure Definitions - -For the purposes of defining the encoding rules for attribute -structures, the BNF definitions in section 4.1 of [RFC2252] will be -used. They are based on the BNF styles of [RFC822]. - -To avoid requiring new syntax support to be added unnecessarily to -existing LDAPv3 directory service implementations (and the -accompanying matching rules, etc. they would entail), a string -encoding is defined for ldapChangeSequenceNumber which can use -CaseIgnoreString matching rules for ordering and equality. - -6.1.1 ldapChangeSequenceNumber - -( 1.3.6.1.4.1.1466.115.121.1.TBD DESC 'LDAP Change Sequence Number' ) - -Values in this syntax are encoded according to the following BNF. -Note there MUST NOT be any whitespace separators, unless they are in -replicaID, which must be encoded according to the instructions below. - -This encoding is specified so that the CaseIgnoreString equality and -ordering rules will work correctly when replicaNumber is used. - -When replicaID is used, CaseIgnoreString comparison rules will not -work unless each replicaID is exactly the same length with no padded - - -Reed [Page 6] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -white spaces (because CaseIgnoreString suppresses duplicate adjacent -white space when it compares two strings). - -LDAPChangeSequenceNumber = GeneralizedZTime "#" S1 "#" replicaID - "#" S2 -GeneralizedZTime = yyyy | mm | dd | hh | mi | ss | "Z" -yyyy = dddd -mm = dd -dd = dd -hh = dd -mi = dd -ss = dd -replicaID = dstring -S1, S2 = numericstring - -The GeneralizedTime is used as described (cf. [X680] section 39.3 case -b) without separators or whitespace, and representing a coordinated -universal time (i.e., Greenwich Mean Time, or GMT). All times -referenced by this syntax MUST be normalized to GMT - no local times, -nor time zone offsets are permitted. To simplify comparisons of two -CSNs, the "Z" MUST be the UTF-8 capital-Z character. - -The ReplicaID represents the specific Replica of this Naming Context -where the event associated with this LDAPChangeSequenceNumber -occurred. Note that in actual transfer, the ReplicaID MAY be -represented by a number (see the specification of the -replicaLookupTable, above). - -S1 and S2 are sequence numbers which are used to order two events with -the same Generalized Time and ReplicaID. In order to use string -matching rules for equality and ordering with values with this -encoding, the length of each field must be consistent. Thus, all -instances of S1 MUST be represented with the same number of digits, -using leading zeros as necessary. The same with S2 and replicaID. - - - - -6.2 Attribute Definitions - - -6.2.1 attributeExclusionFilter - -( 2.16.840.1.113719.142.4.1 NAME 'attributeExclusionFilter' - SYNTAX OCTET STRING - SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) - - - -Reed [Page 7] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -The attributeExclusionFilter is intended to contain a list of -attributes in the form of an AttributeDescriptionList as described in -section 4.5.1. Search Request of [RFC2251] with the following -interpretation: an empty attributeExclusionFilter means that no -attributes are excluded; the special values "*" and "1.1" mean that -ALL attributes are excluded. - -A non-empty attributeExclusionFilter attribute on a replica subEntry -describes the attributes NOT PRESENT on entries held by that replica. -Replicas MUST NOT accept changes for attributes they're not permitted -to hold, per the attributeInclusionFilter and attributeExclusionFilter -attributes on their replica subEntry. - -A non-empty attributeExclusionFilter attribute on a -replicationAgreement subEntry describes which additional attributes -are to be excluded from the updates to be sent from the supplier -replica to the consumer replica. - - -6.2.2 attributeInclusionFilter - -( {2.16.840.1.113719.142.4.2 NAME 'attributeInclusionFilter' - SYNTAX OCTET STRING - SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) - -The attributeInclusionFilter is intended to contain a list of -attributes in the form of an AttributeDescriptionList as described in -section 4.5.1. Search Request of [RFC2251] with the following -interpretation: an empty attributeInclusionFilter means that all -attributes are included; the special value "*" means that ALL -attributes are included; the special value "1.1" is meaningless and is -ignored in this usage. - -A non-empty attributeInclusionFilter attribute on a replica subEntry -describes the attributes that may be PRESENT on entries held by that -replica. Replicas MUST NOT accept changes for attributes they're not -permitted to hold, per the attributeIncludionFilter and -attributeExclusionFilter attributes on their replica subEntry. - - -6.2.3 replicaURI - -(2.16.840.1.113719.142.4.x NAME `replicaURI' - DESC `how to connect to this replica' - SYNTAX ldapURI - USAGE dSAOperation ) - - - -Reed [Page 8] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -6.2.4 replicationStatus - -(2.16.840.1.113719.142.4.3 NAME 'replicationStatus' - DESC 'human readable status of last replication attempt' - SYNTAX DirectoryString - SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) - - -The replicationStatus attribute MAY be used to hold a human readable -message describing the most recent replication session attempt for a -replicationAgreement. - -For example, such a messages might include - -1) 19980805162203Z # Success # - -2) 19980805162322Z # Failure # Server too busy, try again - -3) 19980805170215Z # Failure # Unable to connect to DSA - -4) 19980806002301Z # Failure # Authentication failed - -5) 19980806003201Z # Failure # lost connection, reset by peer - -It is suggested, but not required, that the time of a replication -attempt (completion, if successful or failure, if not), the result of -the attempt, and any additional information about a failure be -included in the string message. - -It is suggested, but not required, that the messages be stored with -language tags (English, French, German, Japanese, Chinese, per [LANG -TAG]) particularly if multiple translations of the error messages are -available to the DSA implementers. - -Note that this is a single-valued attribute. Sequences of status -entries SHOULD be written to log files or other persistent storage, or -in multi-valued replication history attributes, but are not specified -here. - - -6.2.5 replicaType - -(2.16.840.1.113719.142.4.4 NAME 'replicaType' - DESC 'Enum: 0-reserved, 1-Primary, 2-Updateable, 3-ReadOnly, all -others reserved' - EQUALITY integerMatch - SYNTAX INTEGER - SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) - -Reed [Page 9] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -ReplicaType is a simple enumeration, used to identify what kind of -replica is being described in a Replica object entry. - -A ReadOnly replica only accepts LDAP Search operations (to Read -entries, list containers, and search for entries). Because no updates -ever originate from ReadOnly replicas, they never have changes to send -to another replica. However, a ReadOnly replica may be designated a -supplier DSA in a replica agreement, if it is simply passing along -information it receives from other Updateable replicas about entries -and their changes. - -ReadOnly replicas may be incomplete replicas. - -An Updateable replica may accept both LDAP Search operations (to read, -list, or search entries), as well as modification operations (to add, -modify, or delete entries). - -The consequences of having incomplete updateable replicas are not -fully understood. LDAP DSAs MAY require updateable replicas to be -complete replicas. - -A Primary replica is an Updateable replica, but it is "more special" -than other Updateable replicas. When LDAP application want to direct -their operations to a single replica, so that the application can be -sure that all application LDAP modification (add, delete, modify) -operations will be immediately visible to application readers, the -Primary replica is a good choice. Such a use would be consistent with -High Confidence DAP option [X518]. One such application might be a -management application which creates new naming contexts or joins two -naming contexts into a single naming context. Another application -might be one which creates new replicas, or replication agreements. - -There SHOULD be only one Primary replica defined for a naming context -at any time. If applications, expecting there to be a Primary replica -discover, by search or inspection of ReplicaType attributes of the -defined Replicas of a naming context, find more than one _ they should -realize that something is wrong. - -There MAY be NO primary replica defined for a naming context. - -Primary replicas MAY NOT be incomplete replicas. - -The way in which replicas change their type, as from ReadOnly to -Updateable, or Updateable to Primary is outside the scope of this -document. - -Section 5.1 "Replica Type" of [LDUP MODEL] details the permissible -combinations of replica types and sparse/fractional replicas. - -Reed [Page 10] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -6.2.6 SecsToWait Attributes - -The secsToWait attributes document the number of seconds a replica is -to wait after the occurrence of a "category n" change event before -initiating a new replication session for replicationAgreements -governed by an eventScheduledSubentry. The definition of a "category -n" change event is implementation dependent, and may be defined -differently by different directory servers. The absence of a value -for any of these attributes MUST be interpreted as meaning "do not -initiate a replication session for change events of this category". - - -6.2.6.1 secsToWaitCat1 - -( 2.16.840.1.113719.142.4.5.1 NAME 'secsToWaitCat1' - SYNTAX INTEGER - USAGE dSAOperation ) - - -6.2.6.2 secsToWaitCat2 - -( 2.16.840.1.113719.142.4.5.2 NAME 'secsToWaitCat2' - SYNTAX INTEGER - USAGE dSAOperation ) - - -6.2.6.3 secsToWaitCat3 - -( 2.16.840.1.113719.142.4.5.3 NAME 'secsToWaitCat3' - SYNTAX INTEGER - USAGE dSAOperation ) - - -6.2.6.4 secsToWaitCat4 - -( 2.16.840.1.113719.142.4.5.4 NAME 'secsToWaitCat4' - SYNTAX INTEGER - USAGE dSAOperation ) - - -6.2.6.5 secsToWaitCat5 - -( 2.16.840.1.113719.142.4.5.5 NAME 'secsToWaitCat5' - SYNTAX INTEGER - USAGE dSAOperation ) - - - - -Reed [Page 11] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -6.2.7 updateVector - -( 2.16.840.1.113719.142.4.6 NAME 'updateVector' - SYNTAX ldapChangeSequenceNumberSyntax - NO-USER-MODIFICATION USAGE dSAOperation ) - -The attribute updateVector is a multi-valued attribute which contains -information for a replica describing the latest changes received by -the replica from other replicas. - -There may be only one ldapChangeSequenceNumber entry from each replica -in the updateVector. That is to say, there is a unique value -constraint on the ReplicaID component of entries in the list. - - -6.3 Class Definitions - - -6.3.1 nameContext - -( 2.16.840.1.113719.142.6.2.1 NAME 'nameContext' SUP top AUXILIARY ) - - -The nameContext auxiliary class, when present on an object, indicates -the beginning, or root, of a naming context. The naming context is -said to be rooted at the entry with the nameContext auxiliary class in -its list of object classes. The root-most entry of a naming context -is the entry with the nameContext auxiliary class in its list of -object classes. - -Characteristics of the replication topology of a naming context are -defined in the replicaSubentry sub-entries associated with the naming -context. - -The attribute accessControlPolicyOID has been removed from here, and -should be published as an ldapSubEntry subordinate to the nameContext, -instead. - -The attribute nameContextCreationTimestamp used here in previous -drafts has been eliminated as redundant. The ldapChangeSequenceNumber -associated with the nameContext value in the list of objectClasses -attribute serves the same purpose. - - -6.3.2 replicaSubentry - -( 2.16.840.1.113719.142.6.3.1 NAME 'replicaSubentry' SUP ldapSubEntry - STRUCTURAL - -Reed [Page 12] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - - MUST (cn, replicaURI, replicaType) - MAY (attributeExclusionFilter, attributeInclusionFilter, -description, updateVector) ) - -Entries of type replicaSubentry MAY be named by their cn attribute. - -The attributes attributeExclusionFilter and attributeInclusionFilter, -if present, govern which entries and attributes from the local naming -context are to be sent (or not sent) to the replica named in replicaDN -of replica agreements for this replica. The attributeExclusionFilter -names attributes which SHOULD NOT be sent. The -attributeInclusionFilter names attributes which SHOULD be sent. - -The attribute replicaURI contains information in ldapURI format that -can be used to contact (ie, open a connection to) this replica. - -The attribute description contains a human-readable description of the -sub-entry. - -The attribute updateVector contains a set of -ldapChangeSequenceNumbers, one for each of the other replicas for this -naming context, which records, from this replicas perspective, the -last change event received from the other indicated replica. - - -6.3.3 replicaAgreementSubentry - -( 2.16.840.1.113719.142.6.4.1 NAME 'replicaAgreementSubentry' - SUP ldapSubEntry STRUCTURAL - MUST ( cn ) - MAY ( attributeExclusionFilter, description, replicaDN, -replicationMechanismOID, replicationStatus, scheduleDN ) ) - -Entries of type replicaAgreementSubentry MAY be named by their cn -attribute. - -The attributes attributeExclusionFilter, and ldapSearchFilter, if -present, govern which entries and attributes from the local naming -context are to be sent (or not sent) to the replica named in -replicaDN. The attributeExclusionFilter names attributes SHOULD NOT be -sent. Note there is no attributeInclusionFilter, because the list of -attributes that may be sent may not be extended beyond those -documented in the attributeInclusionFilter on the replicaSubentry. - -Processing of allowable changes to be sent is as follows: - -1) the attributeInclusionFilter from the replica subentry defines a - set of attributes which SHOULD be sent, less exclusions; - -Reed [Page 13] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -2) the union of attributes excluded by the attributeExclusionFilter - from the replicasubentry and the attributeExclusionFilter from the - replicaAgreementSubentry defines a set of attributes which SHOULD - NOT be sent; - -3) the subtraction of attributes which SHOULD NOT be sent by (2) from - the attributes which SHOULD be sent by (1) constitute the set of - attributes for which changes MAY be sent. - -The attribute description contains a human-readable description of the -sub-entry. - -The attribute replicaDN of syntax DN names another sub-entry of type -replicaSubentry to whom changes are to be sent. If there is no value -for the replicaDN attribute on a replicaAgreementSubentry, the -replicaAgreementSubentry is ignored. Absence of a value may occur -briefly when replicas and replica agreements are first being created, -or when the replica to which a replica agreement applies is being -deleted. - -The attribute replicationStatus MAY be used to record the most recent -result of an attempt to send changes to the replica named in -replicaDN, whether success, or if failure, the nature of the problem -encountered. - -The attribute schedule, if present, names one or more entries of type -scheduleSubentry which govern the schedule for replication attempts. -If not present, replication MUST be attempted when there are changes -to be sent. - - -6.3.4 eventScheduledSubentry Class - -( 2.16.840.1.113719.142.6.1.1 NAME 'eventScheduledSubentry' - SUP ldapSubEntry STRUCTURAL - MUST ( cn ) - MAY ( description, secsToWaitCat1, secsToWaitCat2, secsToWaitCat3, -secsToWaitCat4, secsToWaitCat5 ) ) - -Note that replication agreements using eventScheduledSubentry policy -are, by definition, supplier-initiated. - -The description attribute may be used by the administrator to document -or comment on this subentry. - -The secsToWaitCat1 attribute documents the number of seconds a replica -is to wait after the occurrence of a "category 1" change event before -initiating a new replication session for replicationAgreements - -Reed [Page 14] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -governed by this eventScheduledSubentry. The definition of a -"category 1" change event is implementation dependent, and may be -defined differently by different directory servers. The absence of a -value for this attribute MUST be interpreted as meaning "do not -initiate a replication session for change events of this category". - -The secsToWaitCat2 _ secsToWaitCat5 attributes are similarly defined -for their respective categoriess of change events. - -6.3.5 timeScheduledSubentry Class - -( 2.16.840.1.113719.142.6.5.1 NAME 'timeScheduledSubentry' - SUP ldapSubEntry STRUCTURAL - MUST ( cn ) - MAY ( description ) ) - - - - -7. Object Identifier Assignments - -The LDUP OID prefix is - -ID ::= OBJECT IDENTIFIER - -ldup ID ::= { joint-iso-ccitt(2) country(16) us(840) - organization(1) novell(113719) ldup(142) } - -The OID assignments defined in this document are: - -Attributes: -attributeExclusionFilter ID ::= 2.16.840.1.113719.142.4.1 -attributeInclusionFilter ID ::= 2.16.840.1.113719.142.4.2 -replicationStatus ID ::= 2.16.840.1.113719.142.4.3 -replicaType ID ::= 2.16.840.1.113719.142.4.4 -secsToWaitClass1 ID ::= 2.16.840.1.113719.142.4.5.1 -secsToWaitClass2 ID ::= 2.16.840.1.113719.142.4.5.2 -secsToWaitClass3 ID ::= 2.16.840.1.113719.142.4.5.3 -secsToWaitClass4 ID ::= 2.16.840.1.113719.142.4.5.4 -secsToWaitClass5 ID ::= 2.16.840.1.113719.142.4.5.5 -updateVector ID ::= 2.16.840.1.113719.142.4.6 - -Object Classes: -eventScheduledSubentry ID ::= 2.16.840.1.113719.142.6.1.1 -nameContext ID ::= 2.16.840.1.113719.142.6.2.1 -replicaSubentry ID ::= 2.16.840.1.113719.142.6.3.1 -replicaAgreementSubentry ID ::= 2.16.840.1.113719.142.6.4.1 -timeScheduledSubentry ID ::= 2.16.840.1.113719.142.6.5.1 - -Reed [Page 15] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - - -Note: Object Class OIDs have version numbers, Attribute OIDs don't. - - -8. Security Considerations - -Many of the attributes and object classes described in this document -should be considered _security sensitive_, and protected from -unintended modification by LDAP servers. Generally, creating Naming -Contexts, Replicas and Replica Agreement entries should only be -allowed by directory administrators who are authorized to do so. - -The values of attributes defined here are intended to control the -behavior of the directory service agents, themselves. Unintended -modification of their values may result in incomplete replication of -data (if ldapSearchFilter or attributeExclusionFilter are changed), -inappropriate disclosure of information (if attributeInclusionFilter -is changed), or updates may be lost (if updateVector is changed). - -To avoid depending to much on the ldapAccessPoint values for other -replicas, connections between LDAP servers for the purpose of -replication MUST ALWAYS be authenticated using an authentication -mechanism appropriate for the nature of information to be exchanged. - - - -9. References - -[LANG TAG] _ M. Wahl, T. Howes, _Use of Language Codes in LDAP_, -Internet draft, draft-ietf-ldapext-lang-01.txt - -[LDUP Model] - J. Merrells, E. Reed, U. Srinivisan, _An Abstract Model -of LDAP Replication_, Internet draft, draft-merrells-ldup-model-01.txt - -[LDUP Requirements] - R. Weiser, E. Stokes _LDAP Replication -Requirements_, Internet draft, draft-weiser-replica-req-02.txt, April -1998 - -[RFC2251] _ M. Wahl, T. Howes, S. Kille, _Lightweight Directory Access -Protocol (v3)_, December 1997, RFC 2251 - -[RFC2252] _ M. Wahl, A. Coulbeck, T. Howes, S. Kille, _Lightweight -Directory Access Protocol (v3): Attribute Syntax Definitions_, -December 1997, RFC 2252 - -[X525] - ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997, -Information Technology _ Open Systems Interconnection _ The Directory: -Replication - -Reed [Page 16] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -[X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, -Information technology _ Abstract Syntax Notation One (ASN.1): -Specification of Basic Notation - - - -10. Copyright Notice - -Copyright (C) The Internet Society (1999). 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. - -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 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." - - -11. Acknowledgements - -The use of subEntry object class to store Replica and Replication -Agreement information is due primarily to the lucid explanation by -Mark Wahl, Innosoft, of how they could be used and extended. - -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 - -Reed [Page 17] - Expires September 9, 2000 - - - -INTERNET-DRAFT 9 March 2000 - LDUP Replication Information Model - -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. - - - -12. Author's Address - - Edwards E. Reed - Reed-Matthews, Inc. - 1064 East 140 North - Lindon, UT 84042 - USA - E-mail: eer@oncalldba.com - - LDUP Mailing List: ietf-ldup@idc.org - - - - - - - - - - - - - - - - - - - - - - - - - -Reed [Page 18] - Expires September 9, 2000 - diff --git a/doc/drafts/draft-ietf-ldup-model-xx.txt b/doc/drafts/draft-ietf-ldup-model-xx.txt deleted file mode 100644 index 1567971548..0000000000 --- a/doc/drafts/draft-ietf-ldup-model-xx.txt +++ /dev/null @@ -1,2468 +0,0 @@ -INTERNET-DRAFT - -draft-ietf-ldup-model-03.txt - - - John Merrells - Netscape Communications Corp. - Ed Reed - Reed-Matthews, Inc. - Uppili Srinivasan - Oracle, Inc. - March 10, 2000 - - LDAP Replication Architecture - -Copyright (C) The Internet Society (1998,1999, 2000). -All Rights Reserved. - -Status of this Memo - -This document is an Internet-Draft and is in full conformance with all -provisions of Section 10 of RFC2026. - -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 made obsolete by other documents at -any time. It is inappropriate to use Internet-Drafts as reference -material or to cite them other than as "work in progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt - -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. - -This draft, file name draft-ietf-ldup-model-03.txt, is intended to be -become a Proposed Standard RFC, to be published by the IETF Working -Group LDUP. Distribution of this document is unlimited. Comments -should be sent to the LDUP Replication mailing list or -to the authors. - -This Internet-Draft expires on 10 September 2000. - - - - - - - -Merrells, Reed, Srinivasan [Page 1] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - - - - - - -1 Abstract - -This architectural document outlines a suite of schema and protocol -extensions to LDAPv3 that enables the robust, reliable, server-to- -server exchange of directory content and changes. - -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 RFC 2119 [RFC2119]. The -sections below reiterate these definitions and include some additional -ones. - - -2 Table of Contents - -1 Abstract......................................................2 -2 Table of Contents.............................................2 -3 Introduction..................................................4 -3.1 Scope.........................................................4 -3.2 Document Objectives...........................................5 -3.3 Document Non-Objectives.......................................6 -3.4 Existing Implementations......................................6 -3.4.1 Replication Log Implementations.........................6 -3.4.2 State-Based Implementations.............................7 -3.5 Terms and Definitions.........................................7 -3.6 Consistency Models............................................8 -3.7 LDAP Constraints..............................................9 -4 Directory Model..............................................10 -4.1 Replica Type.................................................10 -4.1.1 Primary Replica........................................10 -4.1.2 Updatable Replica......................................10 -4.1.3 Read-Only Replica......................................10 -4.1.4 Fractional Replicas....................................10 -4.2 Sub-Entries..................................................11 -4.3 Glue Entries.................................................11 -4.4 Unique Identifiers...........................................11 -4.5 Change Sequence Number.......................................11 -4.5.1 CSN Composition........................................11 -4.5.2 CSN Representation.....................................12 -4.5.3 CSN Generation.........................................12 -4.6 State Change Information.....................................13 -4.1.1 Entry Change State Storage and Representation..........13 -4.1.2 Attribute Change State Storage.........................14 - -Merrells, Reed, Srinivasan [Page 2] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -4.1.3 Attribute Value Change State Storage...................14 -4.2 LDAP Update Operations.......................................14 -5 Information Model............................................15 -5.1 Entries, - Semantics and Relationships............................15 -5.2 Root DSE Attributes..........................................15 -5.3 Naming Context...............................................15 -5.4 Replica Object Class and Entries.............................16 -5.5 Lost and Found Entry.........................................16 -5.6 Replication Agreement Object Class and Entries...............16 -5.6.1 Replication Schedule...................................17 -6 Policy Information...........................................18 -6.1 Schema Knowledge.............................................18 -7 LDUP Update Transfer Protocol Framework......................18 -7.1 Replication Session Initiation...............................19 -7.1.1 Authentication.........................................19 -7.1.2 Consumer Initiated.....................................19 -7.1.3 Supplier Initiated.....................................19 -7.2 Start Replication Session....................................20 -7.2.1 Start Replication Request..............................20 -7.2.2 Start Replication Response.............................20 -7.3 Update Transfer..............................................20 -7.4 End Replication Session......................................20 -7.5 Integrity & Confidentiality..................................21 -8 LDUP Update Protocols........................................21 -8.1 Replication Updates and Update Primitives....................21 -8.2 Fractional Updates...........................................21 -9 LDUP Full Update Transfer Protocol...........................22 -9.1 Full Update Transfer.........................................22 -9.2 Replication Update Generation................................22 -9.3 Replication Update Consumption...............................22 -9.4 Full Update, End Replication Session.........................22 -9.5 Interrupted Transmission.....................................23 -10 LDUP Incremental Update Transfer Protocol....................23 -10.1 Update Vector................................................23 -10.2 Supplier Initiated, Incremental Update, - Start Replication Session................................24 -10.3 Replication Update Generation................................24 -10.3.1 Replication Log Implementation.......................25 -10.3.2 State-Based Implementation...........................25 -10.4 Replication Update Consumption...............................25 -10.5 Update Resolution Procedures.................................25 -10.5.1 URP: Distinguished Names.............................26 -10.5.2 URP: Orphaned Entries................................26 -10.5.3 URP: Distinguished Not Present.......................26 -10.5.4 URP: Schema - Single Valued Attributes...............26 -10.5.5 URP: Schema - Required Attributes....................27 -10.5.6 URP: Schema - Extra Attributes.......................27 - - -Merrells, Reed, Srinivasan [Page 3] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -10.5.7 URP: Duplicate Attribute Values......................27 -10.5.8 URP: Ancestry Graph Cycle............................27 -10.6 Incremental Update, End Replication Session..................27 -10.7 Interrupted Transmission.....................................28 -11 Purging State Information....................................28 -11.1 Purge Vector.................................................28 -11.2 Purging Deleted Entries, Attributes, and Attribute Values....29 -12 Replication Configuration and Management.....................29 -13 Time.........................................................30 -14 Security Considerations......................................31 -15 Acknowledgements.............................................31 -16 References...................................................32 -17 Intellectual Property Notice.................................32 -18 Copyright Notice.............................................33 -19 Authors' Address.............................................33 -20 Appendix A - LDAP Constraints................................34 -20.1 LDAP Constraints Clauses.....................................34 -20.2 LDAP Data Model Constraints..................................35 -20.3 LDAP Operation Behaviour Constraints.........................36 -20.4 New LDAP Constraints.........................................37 -20.4.1 New LDAP Data Model Constraints......................37 -20.4.2 New LDAP Operation Behaviour Constraints.............37 - - - - - - -3 Introduction - - -3.1 Scope - -This architectural document provides an outline of an LDAP based -replication scheme. Further detailed design documents will draw -guidance from here. - -The design proceeds from prior work in the industry, including -concepts from the ITU-T Recommendation X.525 (1993, 1997) Directory -Information Shadowing Protocol (DISP) [X525], experience with widely -deployed distributed directories in network operating systems, -electronic mail address books, and other database technologies. The -emphasis of the design is on: - -1. Simplicity of operation. - -2. Flexibility of configuration. - -3. Manageability of replica operations among mixed heterogeneous - vendor LDAP servers under common administration. - - -Merrells, Reed, Srinivasan [Page 4] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -4. Security of content and configuration information when LDAP servers - from more than one administrative authority are interconnected. - -A range of deployment scenarios are supported, including multi-master -and single-master topologies. Replication networks may include -transitive and redundant relationships between LDAP servers. - -The controlling framework used to define the relationships, types, and -state of replicas of the directory content is defined. In this way the -directory content can itself be used to monitor and control the -replication network. The directory schema is extended to define object -classes, auxiliary classes, and attributes that describe areas of the -namespace which are replicated, LDAP servers which hold replicas of -various types for the various partitions of the namespace, LDAP Access -Points (network addresses) where such LDAP servers may be contacted, -which namespaces are held on given LDAP servers, and the progress of -replication operations. Among other things, this knowledge of where -directory content is located could serve as the basis for dynamic -generation of LDAP referrals. - -An update transfer protocol, which actually brings a replica up to -date with respect to changes in directory content at another replica, -is defined using LDAPv3 protocol extensions. The representation of -directory content and changes will be defined by the LDAP Replication -Update Transfer Protocol sub-team. Incremental and full update -transfer mechanisms are described. Replication protocols are required -to include initial population, change updates, and removal of -directory content. - -Security information, including access control policy will be treated -as directory content by the replication protocols. Confidentiality -and integrity of replication information is required to be provided by -lower-level transport/session protocols such as IPSEC and/or TLS. - - - -3.2 Document Objectives - -The objectives of this document are: - -a) To define the architectural foundations for LDAP Replication, so - that further detailed design documents may be written. For - instance, the Information Model, Update Transfer Protocol, and - Update Resolution Procedures documents. - -b) To provide an architectural solution for each clause of the - requirements document [LDUP Requirements]. - -c) To preserve the LDAP Data Model and Operation Behavior -constraints - defined for LDAP in RFC 2251 [See Appendix A] - -d) To avoid tying the LDUP working group to the schedule of any other - working group. - -e) Not to infringe upon known registered intellectual property rights. - - -Merrells, Reed, Srinivasan [Page 5] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - - - -3.3 Document Non-Objectives - -This document does not address the following issues, as they are -considered beyond the scope of the Working Group. - -a) How LDAP becomes a distributed directory. There are many issues - beyond replication that should be considered. Such as, support for - external references, algorithms for computing referrals from the - distributed directory knowledge, etc. - -b) Specifying management protocols to create naming contexts or new - replicas. LDAP may be sufficient for this. The document describes - how new replicas and naming contexts are represented, in the - directory, as entries, attributes, and attribute values. - -c) How transactions will be replicated. However, the architecture - should not knowingly prevent or impede them, given the Working - Group's incomplete understanding of the issues at this time. - -d) The mapping or merging of disparate Schema definitions. - -e) Support of overlapping replicated regions. - -f) The case where separate attributes of an entry may be mastered by - different LDAP servers. This might be termed a 'Split Primary'. - Replica roles are defined in section 4.1. - -g) The specification of a replication system that supports Sparse - Replication. A Sparse Replica contains a subset of the naming - context entries, being modified by an Entry Selection Filter - criteria associated with the replica. An Entry Selection Filter is - an LDAP filter expression that describes the entries to be - replicated. The design and implementation of this functionality is - not yet well enough understood to specify here. - - - -3.4 Existing Implementations - -In order to define a standard replication scheme that may be readily -implemented we must consider the architectures of current LDAP server -implementations. Existing systems currently support proprietary -replication schemes based on one of two general approaches: log-based -or state-based. Some sections of this text may specifically address -the concerns of one approach. They will be clearly marked. - - - -3.4.1R - eplication Log Implementations - -Implementations based on the original University of Michigan LDAP -server code record LDAP operations to a operation log. During a -replication session operations are replayed from this log to bring the - -Merrells, Reed, Srinivasan [Page 6] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -Consumer replica up to date. Example implementations of this type at -this time are the Innosoft, Netscape, and Open LDAP Directory Servers. - - - -3.4.2S - tate-Based Implementations - -Directory Server implementations from Novell and Microsoft at this -time do not replay LDAP operations from a operation log. When a -replication session occurs each entry in the Replicated Area is -considered in turn, compared against the update state of the Consumer, -and any resultant changes transmitted. These changes are a set of -assertions about the presence or absence of entries, attributes, and -their values. - - - -3.5 Terms and Definitions - -The definitions from the Replication Requirements document have been -copied here and extended. - -For brevity, an LDAP server implementation is referred to throughout -as 'the server'. - -The LDAP update operations; Add, Delete, Modify, Modify RDN (LDAPv2) -and Modify DN (LDAPv3), are collectively referred to as LDAP Update -Operations. - -A Naming Context is a subtree of entries in the Directory Information -Tree (DIT). There may be multiple Naming Contexts stored on a single -server. Naming Contexts are defined in section 17 of [X501]. - -A Naming Context is based at an entry identified as its root and -includes all its subordinate entries down the tree until another -Naming Context is encountered. - -A Replica is an instance of a replicated Naming Context. - -A replicated Naming Context is said to be single-mastered if there is -only one Replica where it may be updated, and multi-mastered if there -is more than one Replica where it may be updated. - -A Replication Relationship is established between two or more Replicas -that are hosted on servers that cooperate to service a common area of -the DIT. - -A Replication Agreement is defined between two parties of a -Replication Relationship. The properties of the agreement codify the -Unit of Replication, the Update Transfer Protocol to be used, and the -Replication Schedule of a Replication Session. - -A Replication Session is an LDAP session between the two servers -identified by a replication agreement. Interactions occur between the -two servers, resulting in the transfer of updates from the supplier -replica to the consumer replica. - -Merrells, Reed, Srinivasan [Page 7] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - -The Initiator of a Replication Session is the initiating server. - -A Responder server responds to the replication initiation request from -the Initiator server. - -A Supplier server is the source of the updates to be transferred. - -A Consumer server is the recipient of the update sequence. - -The Update Transfer Protocol is the means by which the Replication -Session proceeds. It defines the protocol for exchanging updates -between the Replication Relationship partners. - -A Replication Update is an LDAP Extended Operation that contains -updates to be applied to the DIT. The Update Transfer Protocol carries -a sequence of these messages from the Supplier to the Consumer. - -The Update Resolution Procedures repair constraint violations that -occur when updates to a multi-mastered Replica collide. - -A Fractional Entry Specification is a list of entry attributes to be -included, or a list of attributes to be excluded in a replica. An -empty specification implies that all entry attributes are included. - -A Fractional Entry is an entry that contains only a subset of its -original attributes. It results from the replication of changes -governed by a Fractional Entry -Specification. - -A Fractional Replica is a replica that holds Fractional Entries of its -naming context. - - - -3.6 Consistency Models - -This replication architecture supports a loose consistency model -between replicas of a naming context. It does not attempt to provide -the appearance of a single copy of a replica. The contents of each -replica may be different, but over time they will be converging -towards the same state. This architecture is not intended to support -LDAP Clients that require a tight consistency model, where the state -of all replicas is always equivalent. - -Three levels of consistency are available to LDAP Clients, which are -characterized by their deployment topologies. Single-Server, where -there is just the naming context and no replicas. Single-master, where -there are replicas, but only one may be updated. And, multi-master, -where there is more than one replica to which LDAP update operations -may be directed. The consistency properties of each model are rooted -in their serialization of read and write operations. - -1) A single-server deployment of a naming context provides tight -consistency to LDAP applications. LDAP Clients have no choice but to -direct all their operations to a single server, serializing both read - - -Merrells, Reed, Srinivasan [Page 8] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -and write operations. - -2) A single-mastered deployment of a naming context provides both -tight and loose consistency to LDAP applications. LDAP Clients must -direct all write operations to the single updateable replica, but may -direct their reads to any of the replicas. A client experiences tight -consistency by directing all its operations to the single updatable -replica, and loose consistency by directing any read operations to any -other replica. - -3) A multi-mastered deployment of a naming context can provide only -loose consistency to LDAP applications. Across the system writes and -reads are not serialized. An LDAP Client could direct their read and -write operations to a single updateable replica, but they will not -receive tight consistency as interleaved writes could be occurring at -another replica. - -Tight consistency can be achieved in a multi-master deployment for a -particular LDAP application if and only if all instances of its client -are directed towards the same updateable replica, and the application -data is not updated by any other LDAP application. Introducing these -constraints to an application and deployment of a naming-context -ensures that writes are serialized providing tight consistency for the -application. - -Future work could make use of the architecture proposed in this -document as a basis for allowing clients to request session guarantees -from a server when establishing a connection. - - - -3.7 LDAP Constraints - -The LDAP-v3 Internet RFC [LDAPv3] defines a set of Data Model and -Operation Behaviour constraints that a compliant LDAP server must -enforce. The server must reject an LDAP Update Operation if its -application to the target entry would violate any one of these LDAP -Constraints. [Appendix A B contains the original text clauses from RFC -2251, and also a summary.] - -In the case of a single-server or single-mastered naming context all -LDAP Constraints are immediately enforced at the single updateable -replica. An error result code is returned to an LDAP Client that -presents an operation that would violate the constraints. - -In the case of a multi-mastered naming context not all LDAP -Constraints can be immediately enforced at the updateable replica to -which the LDAP Update Operation is applied. This loosely consistent -replication architecture ensures that at each replica all constraints -are imposed, but as updates are replicated constraint violations may -arise -that can not be reported to the appropriate client. Any constraint -violations that occur are repaired by a set of update resolution -procedures. - -Any LDAP client that has been implemented to expect immediate - - -Merrells, Reed, Srinivasan [Page 9] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -enforcement of all LDAP Constraints may not behave as expected -against a multi-mastered naming context. - - - -4 Directory Model - - -This section describes extensions to the LDAP Directory Model that are -required by this replication architecture. - - - -4.1 Replica Type - -Each Replica is characterized with a replica type. This may be -Primary, Updatable, or Read-Only. A Read-Only Replica may be further -defined as being Fractional. - - - -4.1.1 - Primary Replica - -The Primary Replica is a full copy of the Replica, to which all -applications that require tight consistency should direct their LDAP -Operations. There can be only one Primary Replica within the set of -Replicas of a given Naming Context. It is also permissible for none -of the Replicas to be designated the Primary. The Primary Replica MUST -NOT be a Fractional Replica. - - -4.1.2 - Updatable Replica - -An Updatable Replica is a Replica that accepts all the LDAP Update -Operations, but is not the Primary Replica. There could be none, one, -or many Updatable Replicas within the set of Replicas of a given -Naming Context. An Updatable Replica MUST NOT be a Fractional Replica. - - - -4.1.3 - Read-Only Replica - -A Read-Only Replica will accept only non-modifying LDAP operations. -All modification operations shall be referred to an updateable -Replica. The server referred to would usually be a Supplier of this -Replica. - - - -4.1.4 - Fractional Replicas - -Fractional Replicas must always be Read-Only. All LDAP Update -Operations must be referred to an Updatable Replica. The server -referred to would usually be a Supplier of this Fractional Replica. - - -Merrells, Reed, Srinivasan [Page 10] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -4.2 Sub-Entries - -Replication management entries are to be stored at the base of the -replicated naming context. They will be of a 'ldapSubentry' -objectclass -to exclude them from regular searches. Entries with the objectclass -subentry are not returned as the result of a search unless the filter -component "(objectclass=ldapSubentry)" is included in the search -filter. - - - -4.3 Glue Entries - -A glue entry is an entry that contains knowledge of its name only. No -other information is held with it. Such glue entries will be -distinguished through a special object class defined for that purpose. -Glue entries may be created during a replication session to repair a -constraint violation. - - -4.4 Unique Identifiers - -Distinguished names can change, so are therefore unreliable as -identifiers. A Unique Identifier must therefore be assigned to each -entry as it is created. This identifier will be stored as an -operational attribute of the entry, named 'entryUUID'. The entryUUID -attribute is single valued. A consistent algorithm for generating such -unique identifiers should be defined for use in the LDUP standards -documents that detail the LDUP information model and LDUP protocols. - - -4.5 Change Sequence Number - -Change Sequence Numbers (CSNs) are used to impose a total ordering -upon the causal sequence of updates applied to all the replicas of a -naming context. Every LDAP Update Operation is assigned at least one -CSN. A Modify operation MUST be assigned one CSN per modification. - - - -4.5.1 - CSN Composition - -A CSN is formed of four components. In order of significance they -are; the time, a change count, a Replica Identifier, and a -modification number. The CSN is composed thus to ensure the uniqueness -of every generated CSN. When CSNs are compared to determine their -ordering they are compared component by component. First the time, -then the change count, then the replica identifier, and finally the -modification number. - -The time component is a year-2000-safe representation of the real -world time, with a granularity of one second. - -Because many LDAP Update Operations, at a single replica, may be - -Merrells, Reed, Srinivasan [Page 11] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -applied to the same data in a single second, the change count -component of the CSN is provided to further order the changes. Each -replica maintains a count of LDAP update operations applied against -it. It is reset to zero at the start of each second, and is -monotonically increasing within that second, incremented for each and -every update operation. Should LDAP Update Operations occur at -different replicas, to the same data, within the same single second, -and happen to be assigned the same change count number, then the -Replica Identifier is used to further order the changes. - -The Replica Identifier is the value of the RDN attribute on the -Replica Subentry. The Replica Identifier could be assigned -programmatically or administratively, in either case short values are -advised to minimise resource usage. The IA5CaseIgnoreString syntax is -used to compare and order Replica Identifier values. - -The fourth and final CSN component, the modification number, is used -for ordering the modifications within an LDAP Modify operation. - - - -4.5.2 - CSN Representation - -The preferred CSN representation is: - yyyy mm dd hh:mi:ssz # 0xSSSS # replica id # 0xssss - -The 'z' in the time stipulates that the time is expressed in GMT -without any daylight savings time offsets permitted, and the 0xssss -represents the hexadecimal representation of an unsigned -integer. -Implementations must support 16 bit change counts and should support -longer ones (32, 64, or 128 bits). - -An example CSN would be " 1998081018:44:31z#0x000F#1#0x0000 ". The -update assigned this CSN would have been applied at time -1998081018:44:31z happened to be the 16th operation which was applied -in that second, was made against the replica with identifier '1', and -was the first modification of the operation that caused the change. - - - -4.5.3 - CSN Generation - -Because Change Sequence Numbers are primarily based on timestamps, -clock differences between servers can cause unexpected change -ordering. The synchronization of server clocks is not required, though -it is preferable that clocks are accurate. If timestamps are not -accurate, and a server consistently produces timestamps which are -significantly older than those of other servers, its updates will not -have effect and the real world time ordering of updates will not be -maintained. - -However, an implementation may choose to require clock -synchronisation. The Network Time Protocol [NTP] [SNTP] offers a -protocol means by which heterogeneous server hosts may be time -synchronised. - -Merrells, Reed, Srinivasan [Page 12] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - -The modifications which made up an LDAP Modify operation are presented -in a sequence. This must be preserved when the resultant changes of -this operation are replicated. - - - - -4.5.3.1 CSN Generation - Log Based Implementation - - -The modification number component may not be required, since the -ordering of the modifications within an LDAP Modify operation have -been preserved in the operation log. - - -4.5.3.2 CSN Generation - State Based Implementation - - -The modification number component may be needed to ensure that the -order of the modifications within an LDAP Modify operation are -faithfully replicated. - - -4.6 State Change Information - -State changes can be introduced via either LDAP Update Operations or -via Replication Updates. A CSN is included with all changes made to an -entry, its attributes, and attribute values. This state information -must be recorded for the entry to enable a total ordering of updates. -The CSN recorded is the CSN assigned to the state change at the server -where the state change was first made. CSNs are only assigned to state -changes that originate from LDAP Update Operations. - -Each of the LDAP Update Operations change their target entry in -different ways, and record the CSN of the change differently. The -state information for the resultant state changes are recorded at -three levels. The entry level, attribute level, and attribute value -level. The state change may be shown through. - -1) The creation of a deletion CSN for the entry, an attribute, or an - attribute value. - -2) In the addition of a new entry, attribute or attribute value, and - its existence CSN. - -3) An update to an existing attribute, attribute value, entry - distinguished name, or entry superior name, and its update CSN. - - - -4.1.1 - Entry Change State Storage and Representation - -When an entry is created, with the LDAP Add operation, the CSN of the -change is added to the entry as the value of an operational attribute - - -Merrells, Reed, Srinivasan [Page 13] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -named 'createdEntryCSN', of syntax type LDAPChangeSequenceNumber. - - createdEntryCSN ::= csn - -Deleted entries are marked as deleted by the addition of the object -class 'deletedEntry'. The attribute 'deletedEntryCSN', of syntax type -LDAP Change Sequence Number, is added to record where and when the -entry was deleted. Deleted entries are not visible to LDAP clients - -they may not be read, they don't appear in lists or search results, -and they may not be changed once deleted. Names of deleted entries -are available for reuse by new entries immediately after the deleted -entry is so marked. It may be desirable to allow deleted entries to be -accessed and manipulated by management and data recovery applications, -but that is outside the scope of this document. - - deletedEntryCSN ::= csn - -A CSN is recorded for both the RDN, and the Superior DN of the entry. - - -4.1.2A - ttribute Change State Storage - -When all values of an attribute have been deleted, the attribute is -marked as deleted and the CSN of the deletion is recorded. The deleted -state and CSN are stored by the server, but have no representation on -the entry, and may not be the subject of a search operation. This -state information must be stored to enable the Update Resolution -Procedures to be performed. - - - -4.1.3 - Attribute Value Change State Storage - -The Modification CSN for each value is to be set by the server when it -accepts a modification request to the value, or when a new value with -a later Modification CSN is received via Replication. The modified -value and the Modification CSN changes are required to be atomic, so -that the value and its Modification CSN cannot be out of synch on a -given server. The state information is stored by the server, but it -has no representation on the entry, and may not be the subject of a -search operation. - -When the value of an attribute is deleted the state of its deletion -must be recorded, with the CSN of the modifying change. It must be -stored to enable the Update Resolution Procedures to be performed. - - - -4.2 LDAP Update Operations - -The server must reject LDAP client update operations with a CSN that -is older than the state information that would be replaced if the -operation were performed. This could occur in a replication topology -where the difference between the clocks of updateable replicas was too -large. Result code 72, serverClocksOutOfSync, is returned to the -client. - -Merrells, Reed, Srinivasan [Page 14] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -5 Information Model - - -This section describes the object classes of the entries that -represent the replication topology. The operational information for -replication are administered through these entries. The LDUP Working -Group will work towards defining an Internet standard to fully detail -all these schema elements. - - -5.1 Entries, Semantics and Relationships - -This section defines the organization of operational data for directory -replication in terms of the relative placement of the entries that -represent Naming Contexts, its Replicas, and their associated -Replication agreements. This section also describes the purpose of -these objects and abstractly describes their content. -A Naming Context defines an area of DIT with independent replication -policies. There are many mechanisms available to identify the set of -Naming Contexts in a Directory, including through special auxiliary -classes or through operational attributes in root DSE pointing to -such entries. The LDUP information model standards will detail an -appropriate mechanism. - -Entries representing the set of Replicas associated with a Naming -Context are created immediately below (children) the Naming Context -entries. Replica entries are defined as subentries and are -intended to hold attributes that identify the Replica's LDAP Access -Point, its Replica Type, and if it is a Fractional Replica, the -attributes it does or does not hold. The attribute value of the entry's -Relative Distinguished Name (RDN) is termed the Replica Identifier and -is used as a component of each CSN associated with the replica. - -Immediately subordinate to each Replica Subentry are the entries -representing the Replication Agreements between this replica and -another replica on some other server in the network. A Replication -Agreement entry is associated with exactly one remote replica. -These entries are defined to hold attributes identifying -the remote Replica associated with this agreement, the scheduling -policy for replication operations, including times when replication is -to be performed, when it is not to be performed, or the policies -governing event-driven replication initiation another Replica, the -scheduling policy for replication operations, including times when -replication is to be performed, when it is not to be performed, or the -policies governing event-driven replication initiation. - - - -5.2 Root DSE Attributes - -LDUP information model will define Root DSE attributes to identify the -set of naming Contexts and replicas present in an LDAP server. - -5.3 Naming Context - -The LDUP Information Model will implement schema elements for - -Merrells, Reed, Srinivasan [Page 15] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -representing configuration and policy information common for all -replicas of the Naming Context. Attributes for recording the location -and time of creation of naming contexts may also be identified by the -information model. - -In future LDAP Access Control standards would define mechanisms for -identifying the ACL policy associated with a Naming Context as well as -the syntax and semantics of its representation. - - -5.4 Replica Object Class and Entries - -Each Replica is characterized by a replica type. This may be Primary, -Updatable, or Read-Only. The latter two types may be further defined -as being Fractional. The Replica entry will include a Fractional Entry -Specification for a Fractional Replica. - -There is a need to represent network addresses of servers holding -replicas participating in Replication Agreements. For this, -the LDUP information model will define an attribute with an -appropriate syntax to represent an LDAP server addresses with which to -contact replicas. - - -An Update Vector describes the point to which the Replica has been -updated, in respect to all the other Replicas of the Naming Context. -The vector is used at the initiation of a replication session to -determine the sequence of updates that should be transferred. - -Enabling LDAP to be a fully distributed service is not an objective -for the design of LDUP information model, though the information stored -in replica entries could facilitate certain distributed operations. - - -5.5 Lost and Found Entry - -When replicating operations between servers, conflicts may arise that -cause a parent entry to be removed causing its child entries to become -orphaned. In this case the Update Resolution Procedures will make the -Lost and Found Entry the child's new superior. - -Each Replica Entry names it's Lost and Found Entry, which would -usually be an entry below the Replica Entry itself. This well known -place allows administrators, and their tools, to find and repair -abandoned entries. - - - -5.6 Replication Agreement Object Class and Entries - -The Replication Agreement defines: - -1. The schedule for Replication Sessions initiation. - -2. The server that initiates the Replication Session, either the - Consumer or the Supplier. - -Merrells, Reed, Srinivasan [Page 16] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - -3. The authentication credentials that will be presented between - servers. - -4. The network/transport security scheme that will be employed in - order to ensure data confidentiality. - -5. The replication protocols and relevant protocol parameters to be - used for Full and Incremental updates. An OID is used to identify - the update transfer protocol, thus allowing for future extensions - or bilaterally agreed upon alternatives. - -6. If the Replica is Fractional, the Fractional Entry Specification for -the attributes to be included or excluded - -Permission to participate in replication sessions will be controlled, -at least in part, by the presence and content of replica agreements. - -The Supplier must be subject to the access control policy enforced by -the Consumer. Since the access control policy information is stored -and replicated as directory content, the access control imposed on the -Supplier by the Consumer must be stored in the Consumer's Replication -Agreement. - - - -5.6.1 - Replication Schedule - -There are two broad mechanisms for initiating replication sessions: -(1) scheduled event driven and (2) change event driven. The mechanism -used to schedule replication operations between two servers is -determined by the Schedule information that is part of the Replication -Agreement governing the Replicas on those two servers. Because each -Replication Agreement describes the policy for one direction of the -relationship, it is possible that events propagate via scheduled -events in one direction, and by change events in the other. - -Change event driven replication sessions are, by their nature, -initiated by suppliers of change information. The server, which the -change is made against, schedules a replication session in response to -the change itself, so that notification of the change is passed on to -other Replicas. - -Scheduled event driven replication sessions can be initiated by either -consumers or suppliers of change information. The schedule defines a -calendar of time periods during which Replication Sessions should be -initiated. - -Schedule information may include both scheduled and change event -driven mechanisms. For instance, one such policy may be to begin -replication within 15 seconds of any change event, or every 30 minutes -if no change events are received. - - - - - -Merrells, Reed, Srinivasan [Page 17] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -6 Policy Information - - -Administrative policy information governs the behavior of the server -This policy information needs to be consistently known and -applied by all replicas of a Naming Context. It may be -represented in the DIT as sub-entries, attributes, and attribute -values. Auxiliary classes are a convenient way to hold such -policy information and to uniformly replicate them among all its -replicas. For a naming context to be faithfully reproduced, all -applicable prescriptive policy information represented among its -ancestral entries must also be replicated. In all cases such -policy information is transmitted as if it were an element of -the Replica root entry. - -Policy information is always replicated in the same manner as any -other entries, attributes, and attribute values. - - - -6.1 Schema Knowledge - -Schema subentries should be subordinate to the naming contexts to -which they apply. Given our model, a single server may hold replicas -of several naming contexts. It is therefore essential that schema -should not be considered to be a server-wide policy, but rather to be -scoped by the namespace to which it applies. - -Schema modifications replicate in the same manner as other directory -data. Given the strict ordering of replication events, schema -modifications will naturally be replicated prior to entry creations -which use them, and subsequent to data deletions which eliminate -references to schema elements to be deleted. Servers MUST NOT -replicate information about entries which are not defined in the -schema. Servers should not replicate modifications to existing schema -definitions for which there are existing entries and/or attributes -which rely on the schema element. - -Should a schema change cause an entry to be in violation of the new -schema, it is recommended that the server preserve the entry for -administrative repair. The server could add a known object class to -make the entry valid and to mark the entry for maintenance. - - - -7 LDUP Update Transfer Protocol Framework - - -A Replication Session occurs between a Supplier server and Consumer -server over an LDAP connection. This section describes the process by -which a Replication Session is initiated, started and stopped. - -The session initiator, termed the Initiator, could be either the -Supplier or Consumer. The Initiator sends an LDAP extended operation -to the Responder identifying the replication agreement being acted on. -The Supplier then sends a sequence of updates to the Consumer. - -Merrells, Reed, Srinivasan [Page 18] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - -All transfers are in one direction only. A two way exchange requires -two replication sessions; one session in each direction. - - -7.1 Replication Session Initiation - -The Initiator starts the Replication Session by opening an LDAP -connection to its Responder. The Initiator binds using the -authentication credentials provided in the Replication Agreement. -The LDUP Update Transfer Protocol will define the LDAP extended -operation the Initiator should perform to initialize an LDUP session. -For the sake of convenience, this extended LDAP operation for -initializing a replication session is referred to as the "Start -Replication" operation. Among other things, this operation will -identify the role each -server will perform, and what type of replication is to be performed. - -One server is to be the Consumer, the other the Supplier, and the -replication may be either Full or Incremental. - - - -7.1.1 - Authentication - - -The initiation of a Replication Session is to be restricted to -privileged clients. The identity and the credentials for the client -eligible for initiating a replication session will be defined as -attributes within Replication Agreements. - -7.1.2 - Consumer Initiated - -The Consumer binds to the Supplier using the authentication -credentials provided in the Replication Agreement. The Consumer sends -the "Start Replication" extended request to begin the Replication -Session. The Supplier returns a "Start Replication" extended response -containing a response code. The Consumer then disconnects from the -Supplier. If the Supplier has agreed to the replication session -initiation, it binds to the Consumer and behaves just as if the -Supplier initiated the replication. - - - -7.1.3 - Supplier Initiated - -The Supplier binds to the Consumer using the authentication -credentials provided in the Replication Agreement. The Supplier sends -the "Start Replication" extended request to begin the -Replication Session. The Consumer returns a "Start Replication" -extended -response containing a response code, and possibly its Update Vector. -If the Consumer has agreed to the Replication Session initiation, then -the transfer protocol begins. - - - -Merrells, Reed, Srinivasan [Page 19] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - - -7.2 Start Replication Session - -7.2.1S - tart Replication Request - - -The LDUP Update Transfer Protocol would define an LDAP Extended -Request, referred to in this document as "Start Replication Request", -that is sent from the Initiator to Responder. The parameters of the -"Start Replication Request" would identify the Replication Agreement -associated with the session, the Update Transfer Protocol associated \ -with the replication session, and other state information necessary -to resume replication between the two servers. - - -7.2.2S - tart Replication Response - - -The LDUP Update Transfer Protocol would define an LDAP Extended -Response, "Start Replication Response", sent in reply to a Start -Replication Request, from the Responder to the Initiator. The -parameters of the Start Replication Response include an response code, -and an optional Update Vector. - - - -7.3 Update Transfer - -Each Update Transfer Protocol is identified by an OID. An LDUP -conformant server implementation must support those update protocols -that are -defined as mandatory in the Update Transfer Protocol standard , and -may support many others. A server will advertise its -protocols in the Root DSE multi-valued attribute -'supportedReplicationProtocols'. - -The Update Transfer Protocol would define the mechanisms for a -Consumer to receive a complete (full) update or incremental update -based on the current state of replication represented in the Update -Vector. A full update is necessary for initializing a consumer -replica upon establishment of replication agreements. - - - -7.4 End Replication Session - -A Replication Session is terminated by the "End Replication Request" -initiated by the supplier. The purpose of this request and response -is to secure the state of the Update Vector associated with the two -replicas that participated in replication. This is necessary for -proper resumption of replication during subsequent LDUP sessions - - - - -Merrells, Reed, Srinivasan [Page 20] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -7.5 Integrity & Confidentiality - -Data integrity (ie, protection from unintended changes) and -confidentiality (ie, protection from unintended disclosure to -eavesdroppers) SHOULD be provided by appropriate selection of -underlying transports, for instance TLS, or IPSEC. Replication MUST -be supported across TLS LDAP connections. Servers MAY be configured -to refuse replication connections over unprotected TCP connections. - - - - -8 LDUP Update Protocols - - -This Internet-Draft defines two transfer protocols for the supplier to -push changes to the consumer. Other protocols could be defined to -transfer changes, including those which pull changes from the supplier -to the consumer, but those are left for future work. - - - -8.1 Replication Updates and Update Primitives - -Both LDUP Update Protocols define how Replication Updates are -transferred from the Supplier to the Consumer. Each Replication Update -consists of a set of Update Primitives that describe the state changes -that have been made to a single entry. Each Replication Update is -associated with a single entry identified by its UUID. - - - The Update Transfer Protocol would define a set of Update Primitives -each of which codifies an assertion about the state change of an entry -that resulted from a directory update operation. The primitives will -include sufficient data to allow recreation of corresponding state -changes on the consumer's replica. An assertion based approach has -been chosen in such a way that the Primitives are idempotent, meaning -that re-application of a Primitive to an Entry will cause no change to -the entry. This is desirable as it provides some resilience against -some kinds of system failures. - -Each Update Primitive contains a CSN that represents an ordering among -all such primitives generated anywhere in the -network. This ordering information is used by the consumer to reconcile -among those primitives that lead to consistency violation -ier. - - -8.2 Fractional Updates - -When fully populating or incrementally bringing up to date a -Fractional Replica each of the Replication Updates must only contain -updates to the attributes in the Fractional Entry Specification. - - - -Merrells, Reed, Srinivasan [Page 21] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -9 LDUP Full Update Transfer Protocol - - - - -9.1 Full Update Transfer - -This Full Update Protocol provides a bulk transfer of the replica -contents for the initial population of new replicas, and the -refreshing of existing replicas. The LDUP Update Transfer protocol -standard will define the ways for this transfer is initiated. - -The Consumer must replace its entire replica contents with that sent -from the Supplier. - -The Consumer need not service any requests for this Naming Context -whilst the full update is in progress. The Consumer could instead -return a -referral to another replica, possibly the supplier. - - - -9.2 Replication Update Generation - -The entire state of a Replicated Area can be mapped onto a sequence of -Replication Updates, each of which contains a sequence of Update -Primitives that describe the entire state of a single entry. - -The sequence of Replication Updates must be ordered such that no entry -is created before its parent. - - - -9.3 Replication Update Consumption - -A Consumer will receive the Replication Updates, extract the sequence -of Update Primitives, and must apply them to the DIB in the order -provided. - - - -9.4 Full Update, End Replication Session - - -A Full Update should also result in the replication of all appropriate -LDUP meta data (which are part of the replicated naming context), such -as the sub-entry representing the Replica being updated and the Update -Vector associated with it. -The Supplier could be accepting updates whilst the update is in -progress. Once the Full Update has completed, an Incremental Update -should be performed to transfer these changes. - - - - - -Merrells, Reed, Srinivasan [Page 22] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -9.5 Interrupted Transmission - -If the Replication Session terminates before the End Replication -Request is sent, then the Replica could be in an inconsistent state. - Until the replica is restored to a consistent -state, the consumer might not permit LDAP Clients to access the -incomplete replica. The Consumer could refer the Client to the -Supplier Replica, or return an error result code. - - - -10 LDUP Incremental Update Transfer Protocol - - -For efficiency, the Incremental Update Protocol transmits only those -changes that have been made to the Supplier replica that the Consumer -has not already received. In a replication topology with transitive -redundant replication agreements, changes may propagate through the -replica network via different routes. - -The Consumer must not support multiple concurrent replication sessions -with more than one Supplier for the same Naming Context. A Supplier -that attempts to initiate a Replication Session with a Consumer -already participating as a Consumer in another Replication Session -will receive appropriate error. . - - - -10.1 Update Vector - -The Supplier uses the Consumer's Update Vector to determine the -sequence of updates that should be sent to the Consumer. - -Each Replica entry includes an Update Vector to record the point to -which the replica has been updated. The vector is a set of CSN values, -one value for each known updateable Replica. Each CSN value in the -vector corresponds to the most recent change that occurred in an -updateable replica that has been replicated to the replica whose -replication state this Update Vector represents. - -For example, consider two updatable replicas of a naming context, one -is assigned replica identifier '1', the other replica identifier '2'. -Each is responsible for maintaining its own update vector, which will -contain two CSNs, one for each replica. So, if both replicas are -identical they will have equivalent update vectors. - -Both Update Vectors = - -{1998081018:44:31z#0x000F#1#0x0000, 1998081018:51:20z#0x0001#2#0x0000} - -Subsequently, at 7pm, an update is applied to replica '2', so its -update vector is updated. - -Replica '1' Update Vector = - -{1998081018:44:31z#0x000F#1#0x0000, 1998081018:51:20z#0x0001#2#0x0000} - -Merrells, Reed, Srinivasan [Page 23] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - -Replica '2' Update Vector = - -{1998081018:44:31z#0x000F#1#0x0000, 1998081019:00:00z#0x0000#2#0x0000} - -Since the Update Vector records the state to which the replica has -been updated, a supplier server, during Replication Session -initiation, can determine the sequence of updates that should be sent -to the consumer. From the example above no updates need to be sent -from replica '1' to replica '2', but there is an update pending from -replica '2' to replica '1'. - -Because the Update Vector embodies knowledge of updates made at all -known replicas it supports replication topologies that include -transitive and redundant connections between replicas. It ensures that -changes are not transferred to a consumer multiple times even though -redundant replication agreements may exist. It also ensures that -updates are passed across the replication network between replicas -that are not directly linked to each other. - -It may be the case that a CSN for a given replica is absent, for one -of two reasons. - -1. CSNs for Read-Only replicas might be absent because no changes will - have ever been applied to that Replica, so there are no changes to - replicate. - -2. CSNs for newly created replicas may be absent because no changes to - that replica have yet been propagated. - -An Update Vector might also contain a CSN for a replica that no longer -exists. The replica may have been temporarily taken out of service, -or may have been removed from the replication topology permanently. An -implementation may choose to retire a CSN after some configurable time -period. - - - -10.2 Supplier Initiated, Incremental Update, Start Replication Session - -The Consumer Responder must return its Update Vector to the Supplier -Initiator. The Supplier uses this to determine the sequence of -Replication Updates that need to be sent to the Consumer. - - - -10.3 Replication Update Generation - -The Supplier generates a sequence of Replication Updates to be sent to -the consumer. To enforce LDAP Constraint 20.1.6, that the LDAP Modify -must be applied atomically, each Replication Update must contain the -entire sequence of Update Primitives for all the LDAP Operations for -which the Replication Update contains Update Primitives. Stated less -formally, for each primitive the update contains, it must also contain -all the other primitives that came from the same operation. - - -Merrells, Reed, Srinivasan [Page 24] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - - -10.3.1 Replication Log Implementation - -A log-based implementation might take the approach of mapping LDAP -Operations onto an equivalent sequence of Update Primitives. A -systematic procedure for achieving this will be fully described in the -standard document defining Update Reconciliation Procedures. - -The Consumer Update Vector is used to determine the sequence of LDAP -Operations in the operation log that the Consumer has not yet seen. - - - -10.3.2 State-Based Implementation - -A state-based implementation might consider each entry of the replica -in turn using the Update Vector of the consumer to find all the state -changes that need to be transferred. Each state change (entry, -attribute, or value - creation, deletion, or update) is mapped onto -the equivalent Update Primitive. All the Update Primitives for a -single entry might be collected into a single Replication Update. -Consequently, it could contain the resultant primitives of many LDAP -operations. - - - -10.4 Replication Update Consumption - -A Consumer will receive Replication Updates, extract the sequence of -Update Primitives, and must apply them to the DIB in the order -provided. LDAP Constraint 20.1.6 states that the modifications within -an LDAP Modify operation must be applied in the sequence provided. - -Those Update Primitives must be reconciled with the current replica -contents and any previously received updates. In short,, -updates are compared to the state information associated with the item -being operated on. If the change has a more recent CSN, then it is -applied to the directory contents. If the change has an older CSN it -is no longer relevant and its change must not be effected. - -If the consumer acts as a supplier to other replicas then the updates -are retained for forwarding. - - - -10.5 Update Resolution Procedures - -The LDAP Update Operations must abide by the constraints imposed by -the LDAP Data Model and LDAP Operational Behaviour, Appendix A. An -operation that would violate at least one of these constraints is -rejected with an error result code. - -The loose consistency model of this replication architecture and its -support for multiple updateable replicas of a naming context means - - -Merrells, Reed, Srinivasan [Page 25] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -that LDAP Update Operations could be valid at one replica, but not in -another. At the time of acceptance, the accepting -replica may not have received other updates that would cause a -constraint to be violated, and the operation to be rejected. - -Replication Updates must never be rejected because of a violation of -an LDAP Constraint. If the result of applying the Replication Update -causes a constraint violation to occur, then some remedial action must -be taken to satisfy the constraint. These Update Resolution Procedures -are introduced here will be fully defined withinLDUP Update Resolution -Procedures. - - - -10.5.1 URP: Distinguished Names - -LDAP Constraints 20.1.1 and 20.1.10 ensure that each entry in the -replicated area has a unique DN. A Replication Update could violate -this constraint producing two entries, with different unique -identifiers, but with the same DN. The resolution procedure is to -rename the most recently named entry so that its RDN includes its own -unique identifier. This ensures that the new DN of the entry shall be -unique. - - - -10.5.2 URP: Orphaned Entries - -LDAP Constraints 20.1.11 ensures that every entry must have a parent -entry. A Replication Update could violate this constraint producing an -entry with no parent entry. The resolution procedure is to create a -Glue Entry to take the place of the absent parent. The Glue Entry's -superior will be the Lost and Found Entry. This well known place -allows administrators and their tools to find and repair abandoned -entries. - - - -10.5.3 URP: Distinguished Not Present - -LDAP Constraints 20.1.8 and 20.1.9 ensure that the components of an -RDN appear as attribute values of the entry. A Replication Update -could violate this constraint producing an entry without its -distinguished values. The resolution procedure is to add the missing -attribute values, and mark them as distinguished not present, so that -they can be deleted when the attribute values are no longer -distinguished. - - - -10.5.4 URP: Schema - Single Valued Attributes - -LDAP Constraint 20.1.7 enforces the single-valued attribute schema -restriction. A Replication Update could violate this constraint -creating a multi-value single-valued attribute. The resolution - - -Merrells, Reed, Srinivasan [Page 26] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -procedure is to consider the value of a single-valued attribute as -always being equal. In this way the most recently added value will be -retained, and the older one discarded. - - - -10.5.5 URP: Schema - Required Attributes - -LDAP Constraint 20.1.7 enforces the schema objectclass definitions on -an entry. A Replication Update could violate this constraint creating -an entry that does not have attribute values for required attributes. -The resolution procedure is to ignore the schema violation and mark -the entry for administrative repair. - - - -10.5.6 URP: Schema - Extra Attributes - -LDAP Constraint 20.1.3 and 20.1.7 enforces the schema objectclass -definitions on an entry. A Replication Update could violate this -constraint creating an entry that has attribute values not allowed by -the objectclass values of the entry. The resolution procedure is to -ignore the schema violation and mark the entry for administrative -repair. - - - -10.5.7 URP: Duplicate Attribute Values - -LDAP Constraint 20.1.5 ensures that the values of an attribute -constitute a set of unique values. A Replication Update could violate -this constraint. The resolution procedure is to enforce this -constraint, recording the most recently assigned CSN with the value. - - - -10.5.8 URP: Ancestry Graph Cycle - -LDAP Constraint 20.4.2.1 prevents against a cycle in the DIT. A -Replication Update could violate this constraint causing an entry to -become it's own parent, or for it to appear even higher in it's -ancestry graph. The resolution procedure is to break the cycle by -changing the parent of the entry closest to be the lost and found -entry. - - - -10.6 Incremental Update, End Replication Session - -If the Supplier sent none of its own updates to the Consumer, then the -Supplier's CSN within the Supplier's update vector should be updated -with the earliest possible CSN that it could generate, to record the -time of the last successful replication session. The Consumer will -have received the Supplier's Update Vector in the replica sub-entry it -holds for the Supplier replica. - -Merrells, Reed, Srinivasan [Page 27] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - -The Consumer's resultant Update Vector CSN values will be at least as -great as the Supplier's Update Vector. - -The Supplier may request that the Consumer return its resultant Update -Vector so that the Supplier can update its replica sub-entry for the -Consumer Replica. The Supplier requests this by setting a flag in the -End Replication Request. The default flag value is TRUE meaning the -Consumer Update Vector must be returned. - - - -10.7 Interrupted Transmission - -If the Replication Session terminates before the End Replication -Request is sent then the Consumer's Update Vector may or may not be -updated to reflect the updates received. The Start Replication request -includes a Replication Update Ordering flag which states whether the -updates were sent in CSN order per replica. - -If updates are sent in CSN order per replica then it is possible to -update the Consumer Update Vector to reflect that some portion of the -updates to have been sent have been received and successfully applied. -The next Incremental Replication Session will pick up where the failed -session left off. - -If updates are not sent in CSN order per replica then the Consumer -Update can not be updated. The next Incremental Replication Session -will begin where the failed session began. Some updates will be -replayed, but because the application of Replication Updates is -idempotent they will not cause any state changes. - - - -11 Purging State Information - - -The state information stored with each entry need not be stored -indefinitely. A server implementation may choose to periodically, or -continuously, remove state information that is no longer required. The -mechanism is implementation-dependent, but to ensure interoperability -between implementations, the state information must not be purged -until all known replicas have received and acknowledged the change -associated with a CSN. This is determined from the Purge Vector -[11.1]. - -All the CSNs stored that are lower than the Purge Vector may be -purged, because no changes with older CSNs can be replicated to this -replica. - - - -11.1 Purge Vector - -The Purge Vector is an Update Vector constructed from the Update -Vectors of all known replicas. Each replica has a sub-entry for each - -Merrells, Reed, Srinivasan [Page 28] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -known replica stored below its naming context. Each of those entries -contains the last known update vector for that replica. The lowest CSN -for each replica are taken from these update vectors to form the Purge -Vector. The Purge Vector is used to determine when state information -and updates need no longer be stored. - - - -11.2 Purging Deleted Entries, Attributes, and Attribute Values - -The following conditions must hold before an item can be deleted from -the Directory Information Base. - -1) The LDAP delete operation has been propagated to all replication -agreement partners. - -2) All the updates from all the other replicas with CSNs less than the -CSN on the deletion have been propagated to the server holding the -deleted entry (similarly for deleted attributes and attribute values). - -3) The CSN generator of the other Replicas must have advanced beyond -the deletion CSN of the deleted entry. Otherwise, it is possible for -one of those Replicas to generate operations with CSNs earlier than -the deleted entry. - - -12 Replication Configuration and Management - - -Replication management entries, such as replica or replication -agreement entries, can be altered on any updateable replica. These -entries are implicitly included in the directory entries governed by -any agreement associated with this naming context. As a result, all -servers with a replica of a naming context will have access to -information about all other replicas and associated agreements. - -The deployment and maintenance of a replicated directory network -involves the creation and management of all the replicas of a naming -context and replication agreements among these replicas. This section -outlines, through an example, the administrative actions necessary to -create a new replica and establish replication agreements. Typically, -administrative tools will guide the administrator and facilitate these -actions. The objective of this example is to illustrate the -architectural relationship among various replication related -operational information. - -A copy of an agreement should exist on both the supplier and consumer -side for the replication update transfer protocol to be able to start. -For this purpose, the root of the naming context, replica objects and -the replication agreement objects are created first on one of the -servers. A copy of these objects are then manually created on the -second server associated with the agreement. - -The scenario below starts with a server (named DSA1) that holds an -updateable replica of a naming context NC1. Procedures to establish -an updateable replica of the naming context on a second server (DSA2) - -Merrells, Reed, Srinivasan [Page 29] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -are outlined. - -On DSA1: - -1) Add the context prefix for NC1 to the Root DSE attribute - 'replicaRoot' if it does not already exist. - -2) Alter the 'ObjectClass' attribute of the root entry of NC1 to - include the "namingContext" auxiliary class. - -3) Create a replica object, NC1R1, (as a child of the root of NC1) to - represent the replica on DSA1. The attributes include replica type - (updateable, read-only etc.) and DSA1 access point information. - -4) Create a copy of the replica object NC1R2 (after it is created on - DSA2) - -5) Create a replication agreement, NC1R1-R2 to represent update - transfer from NC1R1 to NC1R2. This object is a child of NC1R1. - -On DSA2: - -1) Add NC1's context prefix to the Root DSE attribute 'replicaRoot'. - -2) Create a copy of the root entry of NC1 as a copy of the one in DSA1 - (including the namingContext auxiliary class) - -3) Create a copy of the replica object NC1R1 - -4) Create a second replica object, NC1R2 (as a sibling of NC1R1) to - represent the replica on DSA2. - -5) Create a copy of the replication agreement, NC1R1-R2 - -6) Create a replication agreement, NC1R2-R1, to represent update - transfer from NC1R2 to NC1R1. This object is a sibling of NC1R1- - R2. - -After these actions update transfer to satisfy either of the two -agreements can commence. - -If data already existed in one of the replicas, the update transfer -protocol should perform a complete update of the data associated with -the agreement before normal replication begins. - - - -13 Time - - -The server assigns a CSN for every LDAP update operation it receives. -Since the CSN is principally based on time, the CSN is susceptible to -the Replica clocks drifting in relation to each other (either forwards -or backwards). - -The server must never assign a CSN older than or equal to the last CSN -it assigned. - -Merrells, Reed, Srinivasan [Page 30] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - -The server must reject update operations, from any source, which would -result in setting a CSN on an entry or a value which is earlier than -the one that is there. The error code serverClocksOutOfSync (72) -should be returned. - - -14 Security Considerations - - -The preceding architecture discussion covers the server -authentication, session confidentiality, and session integrity in -sections 7.1.1 and 7.5 - -The internet draft "Authentication Methods" for LDAP, provides a -detailed LDAP security discussion. Its introductory passage is -paraphrased below. [AUTH] - -A Replication Session can be protected with the following security -mechanisms. - -1) Authentication by means of the SASL mechanism set, possibly backed - by the TLS credentials exchange mechanism, - -2) Authorization by means of access control based on the Initiators - authenticated identity, - -3) Data integrity protection by means of the TLS protocol or data- - integrity SASL mechanisms, - -4) Protection against snooping by means of the TLS protocol or data- - encrypting SASL mechanisms, - -The configuration entries that represent Replication Agreements may -contain authentication information. This information must never be -replicated between replicas. - -Updates to a multi-mastered entry may collide causing the Update -Resolution Procedures [10.5] to reject or reverse one of the changes -to the entry. The URP algorithms resolve conflicts by using the total -ordering of updates imposed by the assignment of CSNs for every -operation. As a consequence updates originating from system -administrators have no priority over updates originating from regular -system users. - - - -15 Acknowledgements - - -This document is a product of the LDUP Working Group of the IETF. The -contributions of its members is greatly appreciated. - - - - - -Merrells, Reed, Srinivasan [Page 31] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -16 References - - -[AUTH] - M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan, -"Authentication Methods for LDAP", Internet Draft, draft-ietf-ldapext- -authmeth-02.txt, June 1998. - -[BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the -IETF Standards Process", BCP 11, RFC 2028, October 1996. - -[LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access -Protocol (v3)", RFC 2251, December1997. - -[LDUP Requirements] - R. Weiser, E. Stokes 'LDAP Replication -Requirements', Internet Draft, draft-weiser-replica-req-02.txt, -October, 1999 - -[NTP] - D. L. Mills, "Network Time Protocol (Version 3)", RFC 1305, -March, 1992. - -[RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", RFC 2119. - -[RFC2252] - M. Wahl, A. Coulbeck, T. Howes, S. Kille, 'Lightweight -Directory Access Protocol (v3): Attribute Syntax Definitions', RFC -2252, December 1997. - -[SNTP] - D. L. Mills, "Simple Network Time Protocol (SNTP) Version 4 -for IPv4, IPv6 and OSI", RFC 2030, University of Delaware, October -1996. - -[TLS] - J. Hodges, R. L. "Bob" Morgan, M. Wahl, "Lightweight -Directory Access Protocol (v3): Extension for Transport -Layer Security", Internet draft, draft-ietf-ldapext-ldapv3-tls-01.txt, -June 1998. - -[X501] - ITU-T Recommendation X.501 (1993), ) | ISO/IEC 9594-2:1993, -Information Technology - Open Systems Interconnection - The Directory: -Models - -[X680] - ITU-T Recommendation X.680 (1994) | ISO/IEC 8824-1:1995, -Information technology - Abstract Syntax Notation One (ASN.1): -Specification of Basic Notation - -[X525] - ITU-T Recommendation X.525 (1997) | ISO/IEC 9594-9:1997, -Information Technology - Open Systems Interconnection - The Directory: -Replication - - -17 Intellectual Property Notice - - -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 - - -Merrells, Reed, Srinivasan [Page 32] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -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. [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. - - -18 Copyright Notice - - - Copyright (C) The Internet Society (1998,1999). 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 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. - - -19 Authors' Address - - - John Merrells - Netscape Communications, Inc. - 501 East Middlefield Road - Mountain View - CA 94043 - USA - E-mail: merrells@netscape.com - - -Merrells, Reed, Srinivasan [Page 33] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - Phone: +1 650-937-5739 - - Edwards E. Reed - Reed-Matthews, Inc. - 1064 East 140 North - Lindon - UT 84042 - USA - E-mail: eer@oncalldba.com - Phone: +1 801-796-7065 - - Uppili Srinivasan - Oracle, Inc. - Redwood Shores - CA - USA - E-mail: usriniva@us.oracle.com - Phone: +1 650 506 3039 - - LDUP Engineering Mailing List: ldup-repl@external.cisco.com - LDUP Working Group Mailing List: ietf-ldup@imc.org - - -20 Appendix A - LDAP Constraints - - -20.1 LDAP Constraints Clauses - -This is an enumeration of the Data Model and Operation Behaviour -constraint clauses defined in RFC 2251. [LDAPv3] - -1) Data Model - Entries have names: one or more attribute values from - the entry form its relative distinguished name (RDN), which MUST be - unique among all its siblings. (p5) - -2) Data Model - Attributes of Entries - Each entry MUST have an - objectClass attribute. (p6) - -3) Data Model - Attributes of Entries - Servers MUST NOT permit - clients to add attributes to an entry unless those attributes are - permitted by the object class definitions. (p6) - -4) Relationship to X.500 - This document defines LDAP in terms of - X.500 as an X.500 access mechanism. An LDAP server MUST act in - accordance with the X.500 (1993) series of ITU recommendations when - providing the service. However, it is not required that an LDAP - server make use of any X.500 protocols in providing this service, - e.g. LDAP can be mapped onto any other directory system so long as - the X.500 data and service model as used in LDAP is not violated in - the LDAP interface. (p8) - -5) Elements of Protocol - Common Elements - Attribute - Each attribute - value is distinct in the set (no duplicates). (p14) - -6) Elements of Protocol - Modify Operation - The entire list of entry - modifications MUST be performed in the order they are listed, as a - -Merrells, Reed, Srinivasan [Page 34] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - single atomic operation. (p33) - -7) Elements of Protocol - Modify Operation - While individual - modifications may violate the directory schema, the resulting entry - after the entire list of modifications is performed MUST conform to - the requirements of the directory schema. (p33) - -8) Elements of Protocol - Modify Operation - The Modify Operation - cannot be used to remove from an entry any of its distinguished - values, those values which form the entry's relative distinguished - name. (p34) - -9) Elements of Protocol - Add Operation - Clients MUST include - distinguished values (those forming the entry's own RDN) in this - list, the objectClass attribute, and values of any mandatory - attributes of the listed object classes. (p35) - -10) Elements of Protocol - Add Operation - The entry named in the - entry field of the AddRequest MUST NOT exist for the AddRequest to - succeed. (p35) - -11) Elements of Protocol - Add Operation - The parent of the entry to - be added MUST exist. (p35) - -12) Elements of Protocol - Delete Operation - ... only leaf entries - (those with no subordinate entries) can be deleted with this - operation. (p35) - -13) Elements of Protocol - Modify DN Operation - If there was already - an entry with that name [the new DN], the operation would fail. - (p36) - -14) Elements of Protocol - Modify DN Operation - The server may not - perform the operation and return an error code if the setting of - the deleteoldrdn parameter would cause a schema inconsistency in - the entry. (p36) - - - -20.2 LDAP Data Model Constraints - -The LDAP Data Model Constraint clauses as written in RFC 2251 [LDAPv3] -may be summarised as follows. - -a) The parent of an entry must exist. (LDAP Constraint 11 & 12.) - -b) The RDN of an entry is unique among all its siblings. (LDAP - Constraint 1.) - -c) The components of the RDN must appear as attribute values of the - entry. (LDAP Constraint 8 & 9.) - -d) An entry must have an objectclass attribute. (LDAP Constraint 2 & - 9.) - -e) An entry must conform to the schema constraints. (LDAP Constraint - - -Merrells, Reed, Srinivasan [Page 35] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - - 3 & 7.) - -f) Duplicate attribute values are not permitted. (LDAP Constraint 5.) - - - -20.3 LDAP Operation Behaviour Constraints - -The LDAP Operation Behaviour Constraint clauses as written in RFC 2251 -[LDAPv3] may be summarised as follows. - -A) The Add Operation will fail if an entry with the target DN already -exists. (LDAP Constraint 10.) - -B) The Add Operation will fail if the entry violates data constraints: - - a - The parent of the entry does not exist. (LDAP Constraint 11.) - - b - The entry already exists. (LDAP Constraint 10.) - - c - The entry RDN components appear as attribute values on the - entry. (LDAP Constraint 9.) - - d - The entry has an objectclass attribute. (LDAP Constraint 9.) - - e - The entry conforms to the schema constraints. (LDAP - Constraint 9.) - - f - The entry has no duplicated attribute values. (LDAP -Constraint 5.) - -C) The modifications of a Modify Operation are applied in the order -presented. (LDAP Constraint 6.) - -D) The modifications of a Modify Operation are applied atomically. -(LDAP Constraint 6.) - -E) A Modify Operation will fail if it results in an entry that -violates data constraints: - - c - If it attempts to remove distinguished attribute values. - (LDAP Constraint 8.) - - d - If it removes the objectclass attribute. (LDAP Constraint 2.) - - e - If it violates the schema constraints. (LDAP Constraint 7.) - - f - If it creates duplicate attribute values. (LDAP Constraint - 5.) - -F) The Delete Operation will fail if it would result in a DIT that -violates data constraints: - - a - The deleted entry must not have any children. (LDAP -Constraint 12.) - - - -Merrells, Reed, Srinivasan [Page 36] - Expires 10 September 2000 - - - - - -INTERNET-DRAFT LDAP Replication Architecture March 10, 2000 - - -G) The ModDN Operation will fail if it would result in a DIT or entry -that violates data constraints: - - b - The new Superior entry must exist. (Derived LDAP Data Model - Constraint A) - - c - An entry with the new DN must not already exist. (LDAP - Constraint 13.) - - c - The new RDN components do not appear as attribute values on - the entry. (LDAP Constraint 1.) - - d - If it removes the objectclass attribute. (LDAP Constraint 2.) - - e - It is permitted for the operation to result in an entry that - violates the schema constraints. (LDAP Constraint 14.) - - - -20.4 New LDAP Constraints - -The introduction of support for multi-mastered entries, by the -replication scheme presented in this document, necessitates the -imposition of new constraints upon the Data Model and LDAP Operation -Behaviour. - - - -20.4.1 New LDAP Data Model Constraints - -1) Each entry shall have a unique identifier generated by the UUID -algorithm available through the 'entryUUID' operational attribute. The -entryUUID attribute is single valued. - - - -20.4.2 New LDAP Operation Behaviour Constraints - -1) The LDAP Data Model Constraints do not prevent cycles in the - ancestry graph. Existing constraints Data Model Constraint - 20.4.1 - - (a) and Operation Constraint - 20.4.2 - (B) would prevent this in - the single master case, but not in the presence of multiple - masters. - -2) The LDAP Data Model Constraints state that only the LDAP Modify - Operation is atomic. All other LDAP Update Operations are also - considered to be atomically applied to the DIB. - - - - - - - - - -Merrells, Reed, Srinivasan [Page 37] - Expires 10 September 2000 - - diff --git a/doc/drafts/draft-ietf-ldup-protocol-xx.txt b/doc/drafts/draft-ietf-ldup-protocol-xx.txt deleted file mode 100644 index 9108794f06..0000000000 --- a/doc/drafts/draft-ietf-ldup-protocol-xx.txt +++ /dev/null @@ -1,895 +0,0 @@ - -LDUP Replication Update Protocol -Internet-Draft -Intended Category: Standards Track -Expires: September 10, 2000 - - - Ellen Stokes - IBM Corporation - - Gordon Good - Netscape Communications Corp. - - March 10 2000 - - The LDUP Replication Update Protocol - Filename: draft-ietf-ldup-protocol-01.txt - -Table of Contents - -1. Status of this Memo.............................................2 -2. Abstract........................................................2 -3. Overview of Protocol............................................2 -4. High-level Description of Protocol Flow.........................3 -4.1 Supplier-initiated incremental replication protocol.............3 -4.2. Consumer-initiated replication protocol......................4 -5. Replication protocol element definitions........................5 -5.1 StartFramedProtocolRequest Extended Operation...................5 -5.2 StartFramedProtocolResponse Extended Operation..................6 -5.3 ReplicationUpdate Extended Operation............................7 -5.3.1 UniqueIdentifier.............................................8 -5.3.2 ReplicationPrimitive.........................................8 -5.3.2.1 AddEntryPrimitive.........................................8 -5.3.2.2 MoveEntryPrimitive........................................9 -5.3.2.3 RenameEntryPrimitive......................................9 -5.3.2.4 RemoveEntryPrimitive......................................9 -5.3.2.5 AddAttributeValuePrimitive................................10 -5.3.2.6 RemoveAttributeValuePrimitive.............................10 -5.3.2.7 RemoveAttributePrimitive..................................10 -5.4 EndFramedProtocolRequest Extended Operation.....................11 -5.5 EndFramedProtocolResponse Extended Operation....................11 -5.6 ReplicationUpdateResponse Extended Operation....................12 -6. Semantics of Full and Incremental Update protocols..............13 -7. Summary of response codes.......................................13 -8. Implications for log-based and state-based servers..............13 -9. Replication of access control and schema information............13 -10. Security Considerations.........................................14 -11. Glossary of Terms...............................................14 -12. Acknowledgments.................................................14 -13. References......................................................14 -14. Author's Addresses..............................................15 - - - -Stokes and Good [Page 1] - -Internet-Draft LDUP Workgroup March 10 2000 - - -1. Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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." - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - - This Internet Draft expires September 10, 2000. - - -2. Abstract - - The protocol described in this document is designed to allow one LDAP - server to replicate its directory content to another LDAP server. The - protocol is designed to be used in a replication configuration where - multiple updatable servers are present. Provisions are made in the - protocol to carry information that allows the server receiving - updates to apply a total ordering to all updates in the replicated - system. This total ordering allows all replicas to correctly resolve - conflicts that arise when LDAP clients submit changes to different - servers that later replicate to one another. - - All protocol elements described here are LDAP Version 3 extended - operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. - - Certain terms used in this document are defined in the document "LDAP - Replication Architecture" (draft-ietf-ldup-model-00.txt). - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are - to be interpreted as described in RFC 2119 [KEYWORDS]. - -3. Overview of Protocol - - The LDAP Replication Architecture [ARCHITECTURE] describes the - overall approach used in ensuring consistency of multiple updatable - replicas of directory content. The protocol described in this - document implements the approach desribed in that document. - - - -Stokes and Good [Page 2] - -Internet-Draft LDUP Workgroup March 10 2000 - - - LDAP Version 3 extended operations are used to carry replicated - content from one server to another. The extended operations defined - in this document are used to initiate and end a replication session, - and to exchange updates. These updates carry with them information - that allows the receiving server to apply a total ordering to all of - the updates in a replicated system. All servers that receive - replication updates apply a consistent set of update resolution - policies, described in [URP]. Consistent application of the update - resolution policies ensures that all replicas eventually converge and - contain the same directory data. - - This protocol is based upon the extended operations defined in - [FRAMING]. - - This protocol is intended to meet the requirements set forth in - [REQ]. - -4. High-level Description of Protocol Flow - - The following section provides a high-level overview of the - replication protocol. Throughout this section, the supplier server is - indicated by the letter "S" and the consumer server by the letter - "C". The construct "S -> C" indicates that the supplier is sending an - LDAPv3 extended operation to the consumer, and "C -> S" indicates - that the consumer is sending an LDAPv3 extended operation to the - supplier. - -4.1 Supplier-initiated incremental replication protocol - - S -> C: LDAP bind operation (identity and credentials - used are implementation-defined) - - C -> S: Bind response - - S -> C: StartFramedProtocolRequest LDAPv3 extended - operation. The parameters are: - - 1) The OID for the LDUP incremental replication protocol or the - LDUP total update protocol, depending on whether an incremental - or complete refresh of the replica is to be performed. - 2) A protocol-specific payload containing: - a) The root of replicated area (unambiguously - identifies the replicated area) - b) The supplier's replicaID - c) The protocol initiation type - Supplier-Initiated - in this case. - - C -> S: StartFramedProtocolResponse LDAPv3 extended operation. The - - - -Stokes and Good [Page 3] - -Internet-Draft LDUP Workgroup March 10 2000 - - - parameters are: - - 1) A protocol-specific payload containing: - a) A response code (see section 7) - b) An optional update vector that is included - if and only if the response code is REPL_SUCCESS. - - S -> C: The supplier may send zero or more ReplicationUpdate LDAPv3 - extended operations. The parameters are: - - 1) The UUID of the entry being updated - 2) One or more Replication Primitives (The supplier - may send as many of these as required to bring - the consumer up to date) - - C -> S: At any time, the consumer may send an unsolicited - ReplicationUpdateResponse LDAPv3 extended operation. The - parameters are: - - 1) An optional update vector. If sent, this indicates that - the consumer has committed all updates whose CSNs are - covered by the transmitted update vector [see glossary - for a definition of "covered by"]. - 2) An optional AbortUpdate boolean flag. If a supplier - receives a ReplicationUpdateResponse from a consumer with - the AbortUpdate flag set to true, the supplier server MUST - immediately cease sending updates and terminate its - connection to the consumer. - - S -> C: After all required updates have been sent to the consumer, the - supplier sends an EndFramedProtocolRequest LDAPv3 extended - operation. - - C -> S: The consumer responds by sending an EndFramedProtocolResponse - LDAPv3 extended operation, and then closes the connection. - -4.2. Consumer-initiated replication protocol - - C -> S: LDAP bind operation (identity and credentials - used are implementation-defined) - - S -> C: Bind response - - C -> S: StartFramedProtocolRequest LDAPv3 extended - operation. The parameters are: - - 1) The OID for the LDUP incremental replication protocol or the - LDUP total update protocol, depending on whether an incremental - - - -Stokes and Good [Page 4] - -Internet-Draft LDUP Workgroup March 10 2000 - - - or complete refresh of the replica is to be performed. - 2) A protocol-specific payload containing: - a) The root of replicated area (unambiguously - identifies the replicated area) - b) The consumer's replicaID - c) The protocol initiation type - Consumer-Initiated - in this case. - - S -> C: StartFramedProtocolResponse LDAPv3 extended operation. The - parameters are: - - 1) A protocol-specific payload containing: - a) A response code (see section 7) - - S -> C: The supplier server disconnects from the consumer server, - and then connects to the consumer, beginning a Supplier- - Initiated protocol session (see section 4.1). - - -5. Replication protocol element definitions - -5.1 StartFramedProtocolRequest Extended Operation - - The StartFramedProtocolRequest extended operation is sent by a replication - initiator to a server to indicate that a replication session should - commence. For supplier-initiated replication, the supplier sends this - extended operation to the replication consumer to indicate that a - replication session should commence. For consumer-initiated - replication, the consumer sends this extended operation to the - replication supplier to indicate that the supplier should initiate a - replication session to the consumer as soon as possible. - - The StartFramedProtocolRequest extended operation is defined - in [FRAMING]. When signaling the beginning of a replication - session, then requestValue of the StartFramedProtocolRequest - is set to the following: - - requestValue ::= SEQUENCE { - framedProtocolOID LDAPOID, - framedProtocolPayload OPTIONAL OCTET STRING - } - - The framedProtocolOID of the StartReplicationRequest must be the OID - for the LDUP incremental replication protocol, - 2.16.840.1.113719.1.142.1.4.3, or the LDUP total update protocol, - 2.16.840.1.113719.1.142.1.4.4. See section 7 for information on the - semantic behavior of these update protocols. Implementations MUST - support the two update protocols defined in this document. - - - -Stokes and Good [Page 5] - -Internet-Draft LDUP Workgroup March 10 2000 - - - The framedProtocolPayload of the StartFramedProtocolRequestValue must - be set to the BER-encoding of the following: - - framedProtocolPayload ::= SEQUENCE { - replicaRoot LDAPDN, - replicaID LDAPString, - replicationInitiator ENUMERATED { - supplier (0), - consumer (1) - } - } - - The parameters in the framedProtocolPayload of the - StartFramedProtocolRequestValue are: - - - replicaRoot: the distinguished name of the entry at the top of - the replicated area, and uniquely identifies the unit of - replication. - - - replicaID: the replica identifier of the replication initiator. - Each replica of a given replicated area is identified by a unique - identifier, described in [ARCHITECTURE]. - - - replicationInitiator: used to differentiate between a supplier- - initiated session and a consumer-initiated session. If the - replicationInitiator contains the enumerated value , - then the initiator is the supplier, and the receiver of this - operation should prepare to receive a set of replication updates - (or should reject the operation is replication updates are not - permitted for some reasonm, perhaps due to access control - restrictions). If the replicationInitiator contains the - enumerated value , then the receiver should prepare to - establish a supplier-initiated replication session with the - consumer as soon as possible, updating the replicated are given by - replicaRoot and using the update protocol given by - replicationProtocolOID. - -5.2 StartFramedProtocolResponse Extended Operation - - The StartFramedProtocolResponse extended operation is sent in - response to a StartFramedProtocolRequest extended operation. - - For a supplier-initiated session, the response field of the - StartFramedProtocolResponse extended response indicates that the - consumer is or is not prepared to accept a set of updates. If the - consumer is prepared to accept updates, it sends a response field - containing a success code and the consumer's replica update vector. - If the consumer is unwilling or unable to accept updates, it sends a - - - -Stokes and Good [Page 6] - -Internet-Draft LDUP Workgroup March 10 2000 - - - response field containing an error code. - - For a consumer-initiated session, the response field of the - StartFramedProtocolResponse extended respons indicates that the - supplier is or is not prepared to send a set of updates to the - consumer. If the supplier is prepared to send updates to the - consumer, it sends a response field containing a success code. If the - supplier is unwilling or unable to send updates to the consumer, it - sends a response field containing an error code. In both cases, the - supplier disconnects from the consumer. If the supplier sent a - success code to the consumer, it opens a connection to the consumer - as soon as possible and initiates a supplier-initiated replication - session. - - The StartFramedProtocolResponse extended operation is defined in - [FRAMING]. When responding to a StartFramedProtocolRequest signaling - the beginning of an LDUP replication session, the response field of - the StartFramedProtocolResponse is set to the following: - - StartFramedProtocolResponseValue ::= SEQUENCE { - responseCode LDUPResponseCode, - replicaUpdateVector Attribute, - } - - LDUPResponseCodes are defined in section 8. - - The replicaUpdateVector contains a replica update vector, as defined - in [INFOMOD]. The update vector is encoded as a normal LDAP - attribute, defined in [LDAPv3]. - - -5.3 ReplicationUpdate Extended Operation - -The ReplicationUpdate extended operation carries a set of replication -primitives that represent the desired final state of a single entry. - -The ReplicationUpdate extended operation is defined as follows: - -An LDAPv3 Extended Request is defined in [LDAPv3] as follows: - - ExtendedRequest ::= [APPLICATION 23] SEQUENCE { - requestName [0] LDAPOID - requestValue [1] OCTET STRING OPTIONAL - } - -The requestName of the ReplicationUpdate must be the OID -2.16.840.1.113719.1.142.100.3. - - - - -Stokes and Good [Page 7] - -Internet-Draft LDUP Workgroup March 10 2000 - - -The requestValue of the ReplicationUpdate must be set to the BER- -encoding of the following: - - requestValue ::= SEQUENCE { - uniqueID UniqueIdentifier, - updates SET OF ReplicationPrimitive - } - -5.3.1 UniqueIdentifier - - The Distinguished Name of an entry may be changed (by renaming the - entry), or the entry may not have a distinguished name (if it was - deleted). The Unique Identifier provides an immutable name, - independent of the current name or deletion status, for an entry. All - replicated operations address entries by their Unique Identifiers. - - UniqueIdentifier ::= LDAPString - - -5.3.2 ReplicationPrimitive - - A ReplicationPrimitive carries a single assertion about the the final - state of an entry, attribute, or attribute value. There are seven - types of primitives. - - ReplicationPrimitive ::= CHOICE { - addEntryPrimitive AddEntryPrimitive, - moveEntryPrimitive MoveEntryPrimitive, - renameEntryPrimitive RenameEntryPrimitive, - removeEntryPrimitive RemoveEntryPrimitive, - addAttributeValuePrimitive AddAttributeValuePrimitive, - removeAttributeValuePrimitive RemoveAttributeValuePrimitive, - removeAttributePrimitive RemoveAttributePrimitive - } - - Each primitive applies to the entry referred to by the - uniqueIdentifier in the enclosing ReplicationUpdate extended - operation. - - Each primitive carries an lLDAPChangeSequenceNumber that is used by - the consumer server to correctly resolve update conflicts. [URP] - describes the update reconciliation procedures. - -5.3.2.1 AddEntryPrimitive - - The AddEntryPrimitive is used to add a new entry. - - AddEntryPrimitive ::= [APPLICATION 0] SEQUENCE { - - - -Stokes and Good [Page 8] - -Internet-Draft LDUP Workgroup March 10 2000 - - - csn lDAPChangeSequenceNumber, - superior UniqueIdentifier, - rdn RelativeLDAPDN - } - - Parameters of the AddEntryPrimitive are: - - - csn: The change sequence number of the primitive. - - - superior: The unique identifier of the superior (parent) entry. - - - rdn: The relative distinguished name of the new entry. - -5.3.2.2 MoveEntryPrimitive - - The MoveEntryPrimitive is used to move an entry to a new location in - the DIT. - - MoveEntryPrimitive ::= [APPLICATION 1] SEQUENCE { - csn lDAPChangeSequenceNumber, - superior UniqueIdentifier - } - - Parameters of the MoveEntryPrimitive are: - - - csn: The change sequence number of the primitive. - - - superior: The unique identifier of the new superior (parent) - entry. - -5.3.2.3 RenameEntryPrimitive - - The RenameEntryPrimitive is used to change the RDN of an entry. - - RenameEntryPrimitive ::= [APPLICATION 2] SEQUENCE { - csn lDAPChangeSequenceNumber, - rdn RelativeLDAPDN - } - - Parameters of the RenameEntryPrimitive are: - - - csn: The change sequence number of the primitive. - - - rdn: The new relative distinguished name of the entry. - -5.3.2.4 RemoveEntryPrimitive - - The RemoveEntryPrimitive is used to delete an entry from the DIT. - - - -Stokes and Good [Page 9] - -Internet-Draft LDUP Workgroup March 10 2000 - - - RemoveEntryPrimitive ::= [APPLICATION 3] SEQUENCE { - csn lDAPChangeSequenceNumber - } - - Parameters of the RemoveEntryPrimitive are: - - - csn: The change sequence number of the primitive. - -5.3.2.5 AddAttributeValuePrimitive - - The AddAttributeValuePrimitive is use to add a new attribute value to - an entry. - - AddAttributeValuePrimitive ::= [APPLICATION 4] SEQUENCE { - csn lDAPChangeSequenceNumber, - type AttributeDescription, - value AttributeValue - } - - Parameters of the AddAttributeValuePrimitive are: - - - csn: The change sequence number of the primitive. - - - type: The type of the attribute being added. - - - value: The value being added. Multiple values are not permitted. - -5.3.2.6 RemoveAttributeValuePrimitive - - The RemoveAttributeValuePrimitive is used to remove a particular - attribute value from an entry. - - RemoveAttributeValuePrimitive ::= [APPLICATION 5] SEQUENCE { - csn lDAPChangeSequenceNumber, - type AttributeDescription, - value AttributeValue - } - - Parameters of the RemoveAttributeValuePrimitive are: - - - csn: The change sequence number of the primitive. - - - type: The type of the attribute being removed. - - - value: The value being removed. Multiple values are not - permitted. - -5.3.2.7 RemoveAttributePrimitive - - - -Stokes and Good [Page 10] - -Internet-Draft LDUP Workgroup March 10 2000 - - - The RemoveAttributePrimitive is used to remove an attribute and all - its values from an entry. - - RemoveAttributePrimitive ::= [APPLICATION 6] SEQUENCE { - csn lDAPChangeSequenceNumber, - type AttributeDescription - } - - Parameters of the RemoveAttributePrimitive are: - - - csn: The change sequence number of the primitive. - - - type: The type of the attribute being removed. - - -5.4 EndFramedProtocolRequest Extended Operation - - The EndFramedProtocolRequest extended operation is sent from the - replication supplier to the replication consumer to indicate the end - of the sequence of replication updates. In the event that the - supplier is sending a total update, the requestValue field of the - EndFramedProtocolRequest extended operation contains a replica update - vector. The consumer server must replace its replica update vector, - if present, with the one provided by the supplier. In the event that - the supplier is sending an incremental update, the replica update - vector is absent. - - The EndFramedProtocolRequest extended operation is defined in - [FRAMING]. When used to signal the termination of an LDUP incremental - or total update session, the requestValue field of the - EndFramedProtocolRequest is set to the following: - - requestValue ::= SEQUENCE { - replicaUpdateVector Attribute OPTIONAL, - returnConsumerUpdateVector BOOLEAN - } - - If returnConsumerUpdateVector is TRUE, the consumer server must - return its current update vector to the supplier in the response - field of the EndFramedProtocolResponse extended response (defined in - section 5.5). Typically, the supplier will request the consumer's - update vector for read-only replicas, since the read-only replica - will never initiate a replication session, and will therefore never - have the opportunity to provide its update vector to other servers. - - -5.5 EndFramedProtocolResponse Extended Operation - - - - -Stokes and Good [Page 11] - -Internet-Draft LDUP Workgroup March 10 2000 - - - The EndFramedProtocolResponse extended operation is defined in - [FRAMING]. It is used to respond to a EndFramedProtocolRequest. The - response field of the EndFramedProtocolResponse extended operation is - set to the following: - - response ::= SEQUENCE { - replicaUpdateVector Attribute OPTIONAL - } - - The replicaUpdateVector contains the consumer's current replica - update vector, and is optional. The consumer server should only send - the replicaUpdateVector if requested by the supplier server in the - EndReplicationRequest extended operation. - -5.6 ReplicationUpdateResponse Extended Operation - -The ReplicationUpdateResponse extended operation is sent, unsolicited, -by a consumer to a supplier when the consumer wishes the supplier to -stop sending updates. - -An LDAPv3 extended response is defined in [LDAPv3] as follows: - - ExtendedResponse ::= [APPLICATION 24] SEQUENCE { - COMPONENTS of LDAPResult, - responseName [10] LDAPOID OPTIONAL, - response [11] OCTET STRING OPTIONAL - } - -The responseName of the ReplicationUpdateResponse must be the OID [OID -to be assigned]. - -The response field of the ReplicationUpdateResponse must be set to the -BER-encoding of the following: - - response ::= SEQUENCE { - replicaUpdateVector Attribute OPTIONAL - abortUpdate BOOLEAN - } - -The parameters of the ReplicationUpdateResponse are: - -- An optional update vector. If sent, this indicates that the consumer -has committed all updates whose CSNs are covered by the transmitted -update vector [see glossary for a definition of "covered by"]. - An -optional AbortUpdate boolean flag. If a supplier receives a -ReplicationUpdateResponse from a consumer with the AbortUpdate flag set -to true, the supplier server MUST immediately cease sending updates and -terminate its connection to the consumer. - - - -Stokes and Good [Page 12] - -Internet-Draft LDUP Workgroup March 10 2000 - - -6. Semantics of Full and Incremental Update protocols - -[To be written] - -7. Summary of response codes - -The following list describes the response codes that may be included in -the StartFramedProtocolResponse, EndFramedProtocolResponse, and -ReplicationUpdateResponse extended operations. - - LDUPResponseCode ::= SEQUENCE { - resultCode ENUMERATED { - success (0), - operationsError (1), - protocolError (2), - insufficientAccessRights (50), - busy (51), - excessiveCSNSkew (200), - - other (80) }, - errorMessage LDAPString } - -The meanings of the response codes are as follows: - - success..................... As defined in [LDAPv3]. - operationsError............. As defined in [LDAPv3]. - protocolError............... As defined in [LDAPv3]. - insufficientAccessRights.... Access denied. The identity that the - initiator provided in the bind request does - not have sufficient privileges to perform - the operation. - busy........................ The replica is temporarily unable to accept - updates. - excessiveCSNSkew............ The consumer server has detected that the - CSNs being generated by the supplier are - too small (perhaps because the supplier's - clock was set back). Updates from the - supplier will not be applied. - other....................... Some other error occurred. - -8. Implications for log-based and state-based servers - -To be written, or possibly incorporated into [ARCHITECTURE]. - -9. Replication of access control and schema information - -To be written, or possibly incorporated into [ARCHITECTURE]. - - - - -Stokes and Good [Page 13] - -Internet-Draft LDUP Workgroup March 10 2000 - - -10. Security Considerations - -To be written. - -11. Glossary of Terms - - Covered by: We say that a CSN is "covered by" an update vector if and - only if the CSN is less than or equal to the component of the update - vector corresponding to the replica ID in the CSN. In other words, - given a CSN with components and an update vector with CSNs - ,..., then the CSN is covered - by the RUV if and only if one of the following holds for some value - i: - a) r = ri and t < ti - b) r = ri and t = ti and S < Si - c) r = ri and t = ti and S = Si and s < si - - -12. Acknowledgments - -To be written. - -13. References - - -[ARCHITECTURE] - J. Merrells, E. Reed, U. Srinivasan, "LDAP Replication Architec- - ture", Internet-Draft, draft-ietf-ldup-model-02.txt, October 1999. - - -[FRAMING] - E. Stokes, G. Good, "Extended Operations for Framing LDAP Bulk - Update Operations", Internet-Draft, draft-ietf-ldup-framing-00.txt, - March 2000. - - -[INFOMOD] - E. Reed, "LDAP Replication Information Model", Internet-Draft, - draft-reed-ldup-infomod-00.txt, June 1999. - - -[KEYWORDS] - S. Bradner, "Key Words for use in RFCs to Indicate Requirement Lev- - els", Harvard University, RFC 2119, March 1997. - - -[LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access Protocol - - - -Stokes and Good [Page 14] - -Internet-Draft LDUP Workgroup March 10 2000 - - - (v3)", RFC 2251, December 1997. - - -[REQ]R. Weiser, E. Stokes, "LDAP V3 Replication Requirements", - Internet-Draft, draft-ietf-ldup-replica-req-02.txt, October 1999. - - -[URP]S. Legg, A. Payne, "LDUP Update Reconciliation Procedures", - Internet-Draft, draft-ietf-ldup-urp-02.txt, October 1999. - -14. Author's Addresses - - Ellen Stokes - IBM - 11400 Burnet Rd - Austin, TX 78758 - USA - EMail: stokes@austin.ibm.com - phone: +1 512 838 3725 - fax: +1 512 838 0156 - - Gordon Good - Netscape Communications Corp. - 501 E. Middlefield Rd. - Mailstop MV068 - Mountain View, CA 94043 - USA - EMail: ggood@netscape.com - Phone: +1 650 937-3825 - - 15. Document Revision History - (This section will be removed prior to this document's publication - as a proposed standard) - - Differences between draft-ietf-ldup-protocol-00.txt and - draft-ietf-ldup-protocol-01.txt: - - 1) The document was reworked to use the ldup framed protocol - draft [FRAMING]. - - -Appendix A - Complete ASN.1 Definition - -To be written. - -Full Copyright Statement - -Copyright (C) The Internet Society (1999). All Rights Reserved. - - - -Stokes and Good [Page 15] - -Internet-Draft LDUP Workgroup March 10 2000 - - -This document and translations of it may be copied and furnished to oth- -ers, and derivative works that comment on or otherwise explain it or -assist in its implementation may be prepared, copied, published and dis- -tributed, 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 Stan- -dards 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 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 FIT- -NESS FOR A PARTICULAR PURPOSE. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Stokes and Good [Page 16] diff --git a/doc/drafts/draft-ietf-ldup-replica-req-xx.txt b/doc/drafts/draft-ietf-ldup-replica-req-xx.txt deleted file mode 100644 index ac8a526837..0000000000 --- a/doc/drafts/draft-ietf-ldup-replica-req-xx.txt +++ /dev/null @@ -1,1035 +0,0 @@ - INTERNET-DRAFT Russel F. Weiser - Informational Draft Digital Signature Trust Co. - Expires 21 April 2000 Ellen Stokes - IBM - 21 October 1999 - - - - - - LDAP V3 Replication Requirements - - - - - - Status of this Memo - - - - This document is am Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - - Internet-Drafts are draft documents valid for a maximum of six - months and may be updated, replaced, or obsoleted by other documents - at any time. It is inappropriate to use Internet-Drafts as - reference material or to cite them other than as ``work in - progress.'' - - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/lid-abstracts.txt - - - The list of Internet-Drafts Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - - - - Abstract - - - This document discusses the fundamental requirements for replication - of data accessible via the LDAPv3 [RFC2251] protocol. It is intended - to be a gathering place for general replication requirements needed - to provide interoperability between informational directories. - - - 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 [RFC2119]. - - - - - - - - Weiser & Stokes 21 April 2000 [PAGE 1] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - - - Table of Contents - - - 1.Introduction.....................................................3 - 2. Terminology.....................................................3 - 3. Objective.......................................................5 - 4. Applicability Statement.........................................5 - 5. Replication Model..............................................10 - 6. Replication Protocol...........................................12 - 7. Schema.........................................................13 - 8. Administration and Management Considerations...................13 - 9. Acknowledgement................................................14 - 10. References....................................................15 - 11. Author's Address..............................................15 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Weiser & Stokes 21 April 2000 [Page 2] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - - - - - 1. Introduction - - - The ability to distribute directory information throughout the - network provides a two fold benefit to the network: (1) increasing - the reliability of the directory through fault tolerance, and - (2) brings the directory content closer to the clients using the - data. LDAPÆs acceptance as an access protocol for directory - information is driving the need to distribute LDAP directory content - among servers within enterprise and Internet. Currently LDAP does - not define a replication mechanism and only generally mentions LDAP - shadow servers (see [RFC2251] and [Changelog]) in passing. The - requirements for replication are critical to the successful - deployment and acceptance of LDAP in the market place. - - - - 2. Terminology - - - For the purposes of this document, the following terminology - definitions are used: - - - Area of replication - A whole or portion of a directory tree(DIT) - making up a distinct unit of data to be replicated. This may also be - known as "unit of replication". - - Atomic operation - The ability to treat and contain several updates - or attribute changes as a single operation for replication purposes - to guarantee that the several updates or attribute changes are - propagated to a replica as a single unit. - - Authoritative Master Replica - The Primary updateable replica of the - replicated information. - - - Conflict resolution - Deterministic procedures within replication - protocols, utilized to resolve change information conflicts that may - arise due to conflicting changes affecting a directory entry. - - - Fractional replication - The capability to replicate a subset of - attributes of any given entry. - - Incremental Update - The process of updating a replica, or copy, of - a naming context, by updating only those fields or objects which - have changed. - - - Master Slave, or Single Master Replication - Replication model that - assumes only one server, the master, allows write access to the - replicated data. Note that Master-Slave replication can be - considered a proper subset of multi-master replication. - - - - Weiser & Stokes 21 April 2000 [Page 3] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - - - Multi-Master Replication - A replication model where entries can be - written and updated on any of several updateable replica copies - without requiring communication with other updateable replicas - before the write or update is performed. - - - Naming Context - Suffix of a Sub-tree. A sub-tree of entries held in - a single server [X.500]. - - - One-way Replication - The process of synchronization in a single - direction where the authoritative source information is provided to - a replica. - - - Partial Replication - The capability to replicate some subset of - entries in a naming context. - - - Propagation behavior - The general behavior of the actual - synchronization process between a consumer and a provider of - replication information. - - Read-only Replica - A read-only copy of a replicated directory. A - read-only replica is assumed to be a slave replica of master slave - or single master replication definition. - - - Replica - A single instance of a whole or portion of the Directory - tree (DIT) as defined by area of replication. - - - Replica Ring - A set of servers, which hold in common the same DIT - information as, defined by ôArea of replicationö. These servers may - be managed under a single replication agreement that handles all - members of the set of servers as a group. - - - Replica Cycle - When a change or groups of changes need to be - propagated to the other member of a replica ring. The process of - contacting a replica member would be considered the beginning of a - replication cycle; the termination of communications with a replica - is the end of the cycle whether its due to an error or successful - exchange of update records. - - - Replication - The process of copying portions of naming context - information and content between multiple LDAP servers, such that - certain predefined portions of the information are available from - different servers. Replication can occur between either homogeneous - implementations across heterogeneous platforms (operating systems) - or heterogeneous implementations supporting identical replication - across heterogeneous platforms (operating systems). - - - Sparse Replica - A incomplete copy of a sub-tree which maybe - inclusive with updateable, or Read-only. See Partial replication and - - - - - Weiser & Stokes 21 April 2000 [Page 4] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - Fractional replication. - - - Topology - Refers to the shape of the directed graph describing the - relationships between replicas, as in the replicated directory - topology. - - - Two-way Replication - The process of synchronization where change - information may flow bi-directionally between two replica. - - Update Propagation - Protocol-based process by which directory - replicas are reconciled. - - - Updateable Replica - A Non-authoritative read-writeable copy of the - replicated information. Such that during conflict resolution a - authoritative master takes precedents in resolving conflicts. - - - - 3. Objective - - - The major objective is to provide an interoperable LDAP V3 directory - synchronization protocol which is simple, highly efficient and - flexible enough to support both multi-master and master-slave - replication operations to meet the needs of both the internet and - enterprise environments. - - - 4. Applicability Statement - - - Generally replication can be characterized by looking at data - consistency models across existing technologies. This may provide - insight to LDAP v3 replication requirements. The following is a - brief examination of the following data models. - - - Model 1: Tight Consistency -- Includes environments where all - replicas must always contain exactly the same directory content. Two - phase commit transaction models may be used to preserve transaction - consistency. - - - Model 2: Eventual Consistency or Transient Consistency -- Includes - X.500 Directories, Bayou [XEROX], and NDS (Novell Directory - Services) names service where definite knowledge of the global - replica topology is provided through predetermined replication - agreements. Such that every update propagates to every replica that - it can reach via a path of stepwise eventual connectivity. - Transaction consistency is preserved for transactions directed at - the master server in X.500 implementations. NDS additionally - provides deterministic consistency over time to all replicas due to - its inherent replication policies. - - - - - Weiser & Stokes 21 April 2000 [Page 5] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - Model 3: Limited Effort Eventual Consistency -- Includes Xerox - Clearinghouse [XEROX] that provides a statistical probability of - convergence with global knowledge of replica topology. Similar to - "Eventual Consistency", except where replicas may purge updates - therefore dropping propagation changes when some replica time - boundary is exceeded, thus leaving some changes replicated to a - portion of the replica topology. Transactional consistency is not - preserved, though some weaker constraints on consistency are - available. - - Model 4: Loosest Consistency -- Includes opportunistic or simple - cache where information is provided from the cache until stale. - - - Model 5: Ad hoc -- A copy of a date store where no follow up checks - are made for the accuracy/freshness of the data. - - - Consistency models 2, and 3 involve the use of prearranged - replication agreements or "Predefined Replication Agreements" - between cooperating servers. The complexity of Model 1's use of 2- - phase commit adds additional overhead that should not considered at - this time. Models 4 and 5 involve unregistered replicas which - "pull" updates from another directory server without that server's - knowledge. These models can be considered to violate a directory's - security policies. Therefore models 1, 4, and 5 are declared to be - out of scope of this working group. - - - So through further review of these consistency models two - application areas can then be derived with even further - characterizations of the data types usages. - - Eventual Consistency or Transient Consistency (Model 2) - This model - provides policy configuration through security management - parameters; the data is more dynamic and utilizes dynamic address - information. - - Limited Effort Eventual Consistency (Model 3) - This model matches a - white-pages environment which contains fairly static data and - address information. This model mainly replicates message - attributes. - - Therefore it is believed an LDAP replication should be flexible - enough to cover the above range of capabilities. The generalized use - of LDUP replication environment is to provide for the distribution - of LDAP directory information in order to improve accessibility and - consistency of the information held by the directory. - - - - 4.1 Replication Scenarios - - - - - - Weiser & Stokes 21 April 2000 [Page 6] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - The following directory deployment examples are intended to - substantiate and validate our replication requirements. It is - assumed in all cases that directory implementations from different - vendors are involved. - - 4.1.1 Extranet Example - - - A company has a trading partner to whom it wishes to provide - directory information. This information may be as simple as a - corporate telephone directory, or as complex as an extranet work - flow application. For performance reasons the company may wish to - have a replica of its directory within the Partner Company, rather - than simply exposed beyond its firewall. - - - The requirements, which follow from this scenario, are: - - - One-way replication, single mastered. - - Authentication of clients. - - Common access control and access control identification. - - Secure transmission of updates. - - Selective attribute replication (Fractional Replication), so that - only partial entries can be replicated. - - - - 4.1.2 Consolidation Example - - - Company A acquires company B. In the transition period, whilst the - organizations are merged, both directory services must coexist. - Company A may wish to attach company B's directory to its own. - - The requirements, which follow from this scenario, are: - - - Multi-Master replication. - - Common access control model. Access control model identification. - - Secure transmission of updates. - - Replication between DITs with potentially differing schema. - - - 4.1.3 Replication Heterogeneous Deployment Example - - An organization may deliberately deploy multiple directory services - within their enterprise to employ the differing benefits of each - service. In this case multi-master replication will be required to - ensure that the multiple updateable replicas of the DIT are - synchronized. Some vendors may provide directory clients, which are - tied to their own directory service. - - - The requirements, which follow from this scenario, are: - - - - Multi-Master replication - - - - Weiser & Stokes 21 April 2000 [Page 7] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - - Common access control model and Access control model - identification. - - Secure transmission of updates. - - Replication between DITs with potentially differing schemas. - - 4.1.4 Shared Name Space Example - - - Two organizations may choose to cooperate on some venture and need a - shared name space to manage their operation. Both organizations - will require administrative rights over the shared name space. - - The requirements, which follow from this scenario, are: - - - Multi-Master replication. - - Common access control model and Access control model - identification. - - Secure transmission of updates. - - 4.1.5 Supplier Initiated Replication - - A single master environment, which maintains a number of replicas of - the DIT by pushing changes, based on a defined schedule. - - - The requirements, which follow from this scenario, are: - - - Single-master environment. - - Supplier-initiated replication. - - Secure transmission of updates. - - - 4.1.6 Consumer Initiated Replication - - - Again a single mastered replication topology, but the replica - initiates the replication exchange rather than the master. An - example of this is a replica that resides on a laptop computer that - may run disconnected for a period of time. - - - The requirements, which follow from this scenario, are: - - - Single-master environment. - - Consumer initiated replication. - - Open scheduling (anytime). - - 4.1.7 Prioritized attribute replication - - - The password attribute can provide an example of the requirement for - prioritized attribute replication. A user is working in Utah and the - administrator resides in California. The user has forgotten his - password. So the user calls or emails the administrator to request a - new password. The administrator provides the updated password (a - change). Policy states that this attribute is critical and must be - - - - Weiser & Stokes 21 April 2000 [Page 8] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - available to the user for login immediately (e.g. shortly) after the - administrator changed it. Replication needs to occur immediately for - critical attributes/objects. - - - The requirements, which follow from this scenario, are: - - - Incremental replication of changes. - - Automatic replication on change of certain attributes. - - Replicate based on time/attribute semantics. - - 4.1.8 Bandwidth issues - - - The replication of Server (A) R/W replica (a) in Katmandu is handled - via a dial up phone link to Paris where server (B) R/W replica of - (a) resides. Server (C) R/W replica of(a) is connected by a T1 - connection to server (B). Each connection has a different - performance characteristic. - - - The requirements, which follow from this scenario, are: - - - Minimize repetitive updates when replicating from multiple - replication paths. - - Incremental replication of changes. - - Provide replication cycles to delay and/or retry when connections - can not be reached. - - Allowances for consumer initiated or supplier initiated - replication. - - - 4.1.9 Interoperable Administration and Management - - The administrator with administrative authority of the corporate - directory which is replicated by numerous geographically dispersed - LDAP servers from different vendors notices that the replication - process is not completing correctly as the change log is continuing - to grow and/or error message informs him. The administrator uses his - $19.95 RepCo LDAP directory replication diagnostics tools to look at - Root DSE replica knowledge on server 17 and determines that server - 42 made by LDAPÆRUS Inc. is not replicating properly due to an - Object conflict. Using his Repco Remote repair tools he connects to - server 42 and resolves the conflict on the remote server. - - - The requirements, which follow from this scenario, are: - - - Provides replication audit history. - - Provisions for managing conflict resolution. - - Provide LDAP access to predetermined agreements, topology and - policy attributes. - - Provide operations for comparing replicaÆs content for validity. - - Provide LDAP access to status and audit information. - - - - - Weiser & Stokes 21 April 2000 [Page 9] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - 4.1.10 Enterprise Directory Replication Mesh - - - A Corporation builds a mesh of directory servers within the - enterprise utilizing LDAP servers from various vendors. Five servers - are holding the same area of replication. The predetermined - replication agreement(s) for the enterprise mesh are under a single - management, and the security domain allows a single predetermined - replication agreement to manage the 5 servers replication. - - - The requirements, which follow from this scenario, are: - - - Predefined replication agreements that manage more than a single - area of replication that is held on numerous servers. - - Common support of replication management knowledge across vendor - implementation. - - Rescheduling and continuation of a replication cycle when one - server in a replica ring is busy and/or unavailable. - - 5. Replication Model - - - 5.1 LDAP Replication MUST be allowed to span different vendors - directory services in order to provide interoperability. - - 5.2 All replicas MUST eventually be updated with the changed - information, if specified by the replication policy. - - - 5.3 Replication schedules MUST be configurable to allow for - periodic replication, with the replication period determined by - administrator of the replicated system. - - - 5.4 Replication Model MUST enable replication cycle to be initiated - on change or based on the number of pending changes. - - 5.5 The replication model MUST allow for administrative - initiation of replication cycle for any replica that may have - just come back online or was unavailable during previous - replication cycles. - - 5.6 The replication model MUST support both master-slave and - authoritative multi-updateable replica relationships. - - - 5.7 All replicated information between the master database and its - replica databases MUST be identical including all non-user - modify operational attributes such as time stamps. Note this - does not imply that the entire database is identical from - replica to replica, but that the subset of data, chosen to - replicate is identical from replica to replica. Some - operational attributes may be dynamically evaluated; these - attributes will not necessarily appear to be identical. - - - - - - - Weiser & Stokes 21 April 2000 [Page 10] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - 5.8 In distributed multi-vendor environment, LDAP replication MUST - NOT require all copies of the replicated information be - complete copies of the replicated object. - - - 5.9 LDAP replication MUST encompass common schema objects and - attributes, access control, and name space information. - - - 5.10 Sub-tree Replication MUST be defined to allow for greater - flexibility in replication topologies of the DIT as defined by - the area of replication called partial replication. - - - 5.11 Replication of critical values MUST be synchronized and have - priority over non-critical values. An example of a critical - value might be a password or certificate value. - - 5.12 Replication activities MUST occur within the context of a - predefined replication agreement that addresses proper - knowledge of access requirements and credentials between the - synchronizing directories. Currently X.525 DISP [X.525] - discusses this as a shadowing agreement including such - information as unit of replication, update mode, and access - point defining many of the policies between the master and a - replica. - - - 5.13 The acceptance and usage of the Internet requires that LDAP - replication be available across disparate vendor directory - services. - - - 5.14 LDAP replication MUST provide scalability to both enterprise - and Internet environments, e.g. an LDAP server may provide - replication services to replicas within an enterprise as well - as across the Internet. - - - 5.15 The replication model MUST define deterministic policy such - that replication cycle startup time conflicts between two or - more competing master replicas may be resolved - programmatically. An example might be automatic submission and - rescheduling by one of the masters. In such a case, these - replication "conflicts" MUST be resolved by the replication - policy. - - - 5.16 Any replication capable LDAP server MUST allow replication - where the 2 replicating servers agree they can replicate. This - may be accomplished through administrative agreements assuming - compatible access control model and common schema are provided. - - - 5.17 The replication model MUST be able to handle convergence and - resurrection of attributes and objects. This is a consequence - of delete and move with respect to the replication process. - - - - - Weiser & Stokes 21 April 2000 [Page 11] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - 5.18 It is not realistic to assume that all vendors have cooperating - schemas, but that replication may be allowed between diverse - schema. The Model MAY allow for replication between divergent - schema of objects. - - - 6. Replication Protocol - - - 6.1 The act of replication SHOULD have minimal impact on both the - system and network performance. - - 6.2 The replica synchronization SHOULD be handled in such a manner - as to not saturate network with repetitive entry replication - from multiple synchronization providers points. - - - 6.3 Replication MUST only be allowed after the authentication and - verification of authorization of both the replica and the - source directory. - - - 6.4 The transport for LDAP synchronization MUST allow for the - integrity and confidentiality of each replicated server. - - - 6.5 Replicated data MUST be transferable in a secure manner. - - - 6.6 Replication protocol MUST provide for recovery and rescheduling - of a replication cycle due to a replication initiation - conflicts (e.g. consumer busy replicating with other servers) - and or loss of connection(e.g. supplier cannot reach a - replica). The replication protocol MUST include restarting at - the last acknowledged update prior to interruption rather than - re-sending updates it had already sent to a consuming replica. - - - 6.7 LDAP replication MUST allow for full update to facilitate - replica initialization and reset loading utilizing a - standardized format such as LDIF [LDIF] format. - - 6.8 The replication standard SHOULD NOT limit the size of a - replica. The area of replication is defined to be a whole or - portion of a DIT, also allowing a portion of a naming context - to be replicated. Incremental replication SHOULD be allowed. - - 6.9 The replication agreements MUST accommodate multiple servers - receiving the same replica under a single predefined agreement. - - - 6.10 The replication protocol MUST allow either a master or replica - to initiate the replication process. - - - 6.11 Additionally the initiator MUST be allowed to determine - whether it will become a consumer or supplier during the - synchronization startup process. This would allow a replica to - - - - Weiser & Stokes 21 April 2000 [Page 12] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - be periodically connected and synchronized from remote sites at - the local administrator's discretion. - - - 6.12 Multiple LDAP changes to a single server: If transactional - consistency is propagated during replication, then multiple LDAP - changes submitted to a single server SHOULD BE treated as a - single 'atomic unit of work'. - - - 6.13 An LDAP Replication Standard SHOULD NOT limit the transaction - rate of a replication session. - - - 6.14 Entry change information MUST be purged or discarded in a - timely manner when change information becomes outdated due to - propagated to all replica members. - - - - - 7. Schema - - - 7.1 Replica knowledge MUST be provided as DSE attributes. - - 7.2 The Replication Protocol documents MUST define standard schema - for representing replication agreements, and MUST define the - semantics associated with modifying the attributes of - replication agreements. The documents MUST also define a - standard method for determining the location of these - agreements accessible utilizing LDAP. - - - 7.3 The Replication Protocol documents MUST define standard schema - for publishing state information about a given replica, and - MUST define a standard method for determining the location of - this information. - - - 7.4 A location independent management point MUST be defined to - provide authorized administrators with well known access to the - replication policies, regardless of network location. - - - 7.5 Replication agreements of all servers containing replicated - information MUST be accessible via LDAP. - - - 7.6 All objects MUST be uniquely identifiable throughout the object - lifetime . - - - - - 8. Administration and Management Considerations - - - - 8.1 Replication policies MUST allow replication of changed - information to be administratively postponed to a more - - - - Weiser & Stokes 21 April 2000 [Page 13] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - convenient period. - - - 8.2 Allowance for non-scheduled replication of a replica MUST be - provided upon request such that the replica server has been - down or unconnected for a period of time. - - - 8.3 Each copy of a replica MUST maintain audit history information - of which servers it has replicated with and which servers have - replicated with it. - - 8.4 A replica MUST store conflicted versions of the replicated - object to allow optional human review and intervention. - - - 8.5 Access to replication predetermined agreements, topologies, and - policies attributes MUST be provided through LDAP access. - - - 8.6 The capability to check the differences between two replicas - for the same information SHOULD be provided for. This should - entail a client invoking an operation at some server, which - causes that server to extract the contents from some other - server it has a replication agreement with and report the - differences back to the client as the result. - - - 8.7 Authenticated access SHOULD be provided so that Administrative - LDAP clients may query a server for the current state and - replication history for each replica that the server maintains - replication agreements with. - - - 8.8 The ability to view replication conflicts, and override the - resolution derived by the replication policy MUST be provided. - - - 8.9 The deletion of sensitive data MUST be handled in an orderly - manner so that at no time will that data be available without - proper access control. That is, access control information - (ACI) associated with sensitive data must be deleted after or - simultaneously with the delete of the sensitive data. Likewise, - when adding sensitive data, ACI MUST be added first or - simultaneously with the addition of that data. - - - - - 9. Acknowledgement - - - This document is based on input from IETF members interested in LDUP - Replication. - - - - - - - - - Weiser & Stokes 21 April 2000 [Page 14] - - - INTERNET-DRAFT LDAP Replication Requirements 21 October 1999 - - - - - - 10. References - - - - [RFC2251] M. Wahl, T. Howes, S. Kille "Lightweight Directory Access - Protocal", RFC 2251. - - - [RFC2119] S.Bradner, " Key words for use in RFCs to indicate - Requirement Levels", RFC 2119. - - - [LDIF] Gordon Good, "The LDAP Data Interchange Format (LDIF)", - Internet draft, draft-ietf-asid-ldif-00.txt, November 1996. - - - [Changelog] Gordon Good, "Definitions of an Object Class to Hold - LDAP Change records", Internet Draft, draft-ietf-asid-changelog- - 00.txt, November 1996. - - - [X.501] ITU-T Recommendation X.501 (1993), | ISO/IEC 9594-2: 1993, - Information Technology - Open Systems Interconnection - The - Directory: Models - - [XEROX] Hauser, C. "Managing update conflicts in Bayou, a weakly - connected replicated storage system". Palo Alto, CA: Xerox PARC, - Computer Science Laboratory; 1995 August; CSL-95-4. [CSL-95-04] - - - - 11. Author's Address - - - Russel F. Weiser - Digital Signature Trust Co. - One South Main Street - Salt Lake City, Utah 84111 - USA - - - E-mail: rweiser@digsigtrust.com - Telephone: +1-801-983-4415 - Fax +1-801-983-4408 - - - - Ellen J. Stokes - IBM - 11400 Burnet Rd. - Austin, Texas 78758 - USA - - E-mail: stokes@austin.ibm.com - Telephone: +1-512-838-3725 - Fax: +1-512-838-0156 - - - - - - Weiser & Stokes 21 April 2000 [Page 15] diff --git a/doc/drafts/draft-ietf-ldup-subentry-xx.txt b/doc/drafts/draft-ietf-ldup-subentry-xx.txt deleted file mode 100644 index aa8306bf4a..0000000000 --- a/doc/drafts/draft-ietf-ldup-subentry-xx.txt +++ /dev/null @@ -1,286 +0,0 @@ - - - - - - -INTERNET-DRAFT -draft-ietf-ldup-subentry-03.txt - Ed Reed - Reed-Matthews, Inc. - July 13, 2000 - -LDAP Subentry Schema - - -1. Status of this Memo - -This document is an Internet-Draft and is in full -conformance with all provisions of Section 10 of RFC2026. - -Internet-Drafts are working documents of the Internet -Engineering Task Force (IETF), its areas, and its working -groups. Note that other groups may also distribute working -documents as Internet-Drafts. - -Internet-Drafts are draft documents valid for a maximum of -six months and may be updated, replaced, or obsoleted by -other documents at any time. It is inappropriate to use -Internet-Drafts as reference material or to cite them other -than as "work in progress." - -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt. - -The list of Internet-Draft Shadow Directories can be -accessed at http://www.ietf.org/shadow.html. - -This Internet-Draft expires on January 13, 2001. - - -2. Abstract - -This document describes an object class called ldapSubEntry -which MAY be used to indicate operations and management -related entries in the directory, called LDAP Subentries. -This version of this document is updated with an assigned -OID for the ldapSubEntry object class. - -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 RFC 2119 [RFC2119]. The sections below -reiterate these definitions and include some additional -ones. - - -Reed . [Page 1] - Expires January 13, 2001 - - -INTERNET-DRAFT 13 July 2000 - LDAP Subentry Schema - -3. Definition - - -3.1 ldapSubEntry Class - -( 2.16.840.1.113719.2.142.6.1.1 NAME 'ldapSubEntry' - DESC 'LDAP Subentry class, version 1' - SUP top STRUCTURAL - MAY ( cn ) ) - -The class ldapSubEntry is intended to be used as a super- -class when defining other structural classes to be used -as LDAP Subentries, and as the structural class to which -Auxiliary classes may be added for application specific -subentry information. Where possible, the use of Auxiliary -classes to extend ldapSubEntries is strongly preferred. - -The presence of ldapSubEntry in the list of super-classes -of an entry in the directory makes that entry an LDAP -Subentry. Object classes derived from ldapSubEntry are -themselves considered ldapSubEntry classes, for the purpose -of this discussion. - -LDAP Subentries MAY be named by their commonName attribute -[LDAPv3]. Other naming attributes are also permitted. - -LDAP Subentries MAY be containers, unlike their [X.501] -counterparts. - -LDAP Subentries MAY be contained by, and will usually be -located in the directory information tree immediately -subordinate to, administrative points and/or naming -contexts. Further (unlike X.500 subentries), LDAP -Subentries MAY be contained by other LDAP Subentries (the -way organizational units may be contained by other -organizational units). Deep nestings of LDAP Subentries -are discouraged, but not prohibited. - -LDAP Subentries SHOULD be treated as "operational objects" -in much the same way that "operational attributes" are not -regularly provided in search results and read operations -when only user attributes are requested). - -LDAP servers SHOULD implement the following special -handling of ldapSubEntry entries: - -a) search operations which include a matching criteria -"objectclass=ldapSubEntry" MUST include entries derived - -Reed . [Page 2] - Expires January 13, 2001 - - - -INTERNET-DRAFT 13 July 2000 - LDAP Subentry Schema - -from the ldapSubEntry class in the scope of their -operations; - -b) search operations which do not include a matching -criteria "objectclass=ldapSubEntry" MUST IGNORE entries -derived from the ldapSubEntry class, and exclude them from -the scope of their operations. - -The combination of SHOULD and MUST in the special handling -instructions, above, are meant to convey this: Servers -SHOULD support this special handling, and if they do they -MUST do it as described, and not some other way. - - - -4. Security Considerations - -LDAP Subentries will frequently be used to hold data which -reflects either the actual or intended behavior of the -directory service. As such, permission to read such -entries MAY need to be restricted to authorized users. -More importantly, IF a directory service treats the -information in an LDAP Subentry as the authoritative source -of policy to be used to control the behavior of the -directory, then permission to create, modify, or delete -such entries MUST be carefully restricted to authorized -administrators. - - - -5. References - -[LDAPv3] S. Kille, M. Wahl, and T. Howes, "Lightweight -Directory Access Protocol (v3)", RFC 2251, December 1997 - -[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993 - - - -6. Copyright Notice - -Copyright (C) The Internet Society (1999). 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 - -Reed . [Page 3] - Expires January 13, 2001 - - - -INTERNET-DRAFT 13 July 2000 - LDAP Subentry Schema - -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 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." - - -7. Acknowledgements - -The use of subEntry object class to store Replica and -Replication Agreement information is due primarily to the -lucid explanation by Mark Wahl, Innosoft, of how they could -be used and extended. - -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. - - - -Reed . [Page 4] - Expires January 13, 2001 - - - -INTERNET-DRAFT 13 July 2000 - LDAP Subentry Schema - -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. Author's Address - - Edwards E. Reed - Reed-Matthews, Inc. - 1064 E 140 North - Lindon, UT 84042 - USA - E-mail: eer@oncalldba.com - - LDUP Mailing List: ietf-ldup@imc.org - LDAPEXT Mailing List: ietf-ldapext@netscape.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Reed . [Page 5] - Expires January 13, 2001 - diff --git a/doc/drafts/draft-ietf-ldup-urp-xx.txt b/doc/drafts/draft-ietf-ldup-urp-xx.txt deleted file mode 100644 index cb49fddafb..0000000000 --- a/doc/drafts/draft-ietf-ldup-urp-xx.txt +++ /dev/null @@ -1,1627 +0,0 @@ - - - - - - -INTERNET-DRAFT S. Legg -draft-ietf-ldup-urp-03.txt Adacel Technologies - A. Payne - Telstra - June 29, 2000 - - - LDUP Update Reconciliation Procedures - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - Status of this Memo - - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress". - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This draft is published by the IETF LDUP Working Group. Distribution - of this document is unlimited. Comments should be sent to the LDUP - Replication mailing list or to the authors. - - This Internet-Draft expires on 29 December 2000. - - 1. Abstract - - This document describes the procedures used by LDAP [LDAPv3] or X.500 - [X500] directory servers to reconcile updates performed by - autonomously operating directory servers in a distributed, replicated - directory service. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - - - -Legg & Payne Expires 29 December 2000 [Page 1] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - document are to be interpreted as described in RFC 2119 [RFC2119]. - - - 2. Table of Contents - - 1. Abstract 1 - 2. Table of Contents 2 - 3. Introduction 2 - 4. Model Extensions 3 - 4.1 Unique Identifier 3 - 4.2 Timestamps & Existence 3 - 4.3 Replication Primitives 4 - 4.4 Lost & Found 5 - 5. Replication Procedures 6 - 5.1 Processing LDAP, DAP or DSP Operations on the DIT 6 - 5.1.1 Add Entry 7 - 5.1.2 Remove Entry 8 - 5.1.3 Modify Entry 8 - 5.1.4 Modify DN 10 - 5.2 Generating Replication Primitives 10 - 5.3 Processing Replication Primitives on the DIT 12 - 5.3.1 Saving Deletion Records 13 - 5.3.2 Glue Entries 14 - 5.3.3 Generating Change Sequence Numbers 14 - 5.3.4 Comparison of Attribute Values 15 - 5.3.5 Entry Naming 15 - 5.3.6 Processing Add Attribute Value Primitive 18 - 5.3.7 Processing Remove Attribute Value Primitive 19 - 5.3.8 Processing Remove Attribute Primitive 20 - 5.3.9 Processing Add Entry Primitive 20 - 5.3.10 Processing Remove Entry Primitive 21 - 5.3.11 Processing Move Entry Primitive 22 - 5.3.12 Processing Rename Entry Primitive 23 - 6. Security Considerations 24 - 7. Acknowledgements 25 - 8. References 25 - 9. Intellectual Property Notice 26 - 10. Copyright Notice 26 - 11. Authors' Addresses 27 - - - 3. Introduction - - Each DAP, LDAP or DSP operation successfully performed by a directory - server is subsequently reported to other directory servers with which - it has a replication agreement as a set of one or more simple - timestamped replication primitives. These primitives reflect the - intended final state of an update operation rather than the specific - - - -Legg & Payne Expires 29 December 2000 [Page 2] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - changes required to achieve that state. - - A directory server will receive replication primitives from its - various agreement partners according to the agreement schedules. - Those primitives MUST be reconciled with the current directory server - contents. In broad outline, received replication primitives are - compared to the timestamp information associated with the directory - data item being operated on. If the primitive has a more recent - timestamp a change in the directory contents is made (which may - involve only the revision of the timestamp). If the directory server - has other replication agreements then the change will be reflected in - primitives sent during replication sessions for those other - agreements. If the primitive has an older timestamp it is no longer - relevant and is simply ignored. - - The Update Reconciliation Procedures are designed to produce a - consistent outcome at all participating directory servers regardless - of the order in which the primitives are received and processed. The - primitives can also be safely replayed in the event that an exchange - of replication information with another directory server is - interrupted. This greatly simplifies the recovery mechanisms - required in the replication protocol. - - 4. Model Extensions - - This section describes the extensions to the data model required to - effect multi-master replication. - - 4.1 Unique Identifier - - A Unique Identifier is associated with each entry in the global DIT. - This Unique Identifier MUST be globally unique for all time in the - Directory. This can be achieved by defining a unique prefix for each - directory server and then ensuring that the suffix of the Unique - Identifier is locally unique. - - The Unique Identifier for an entry is held in the entryUUID - operational attribute. - - Some pre-allocated global Unique Identifier values are used to - indicate the X.500 global root entry, and the Lost & Found entry (see - Section 4.4). - - 4.2 Timestamps & Existence - - The timestamp for a replication primitive or directory data item is - in the form of a Change Sequence Number (CSN). The components of the - CSN are, from most significant to least significant, a time in - - - -Legg & Payne Expires 29 December 2000 [Page 3] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - seconds, a change count, a Replica Identifier and a modification - number. Notionally a CSN is associated with an entry's Relative - Distinguished Name (the Name CSN), the reference to its superior - entry (the Parent CSN) and each of its attribute values (including - the distinguished values and operational attribute values), to record - the time of the most recent action on that part of the entry. - - The entry itself has a CSN (the Entry CSN) asserting the most recent - time at which the entry was added. An entry is permitted to be - removed and then re-added at one or more directory servers. In this - context re-adding an entry means reusing the Unique Identifier of a - removed entry and does not refer to the case of reusing the RDN of a - removed entry. The reuse of a Unique Identifier can arise by the - explicit action of a directory administrator to restore an entry that - was mistakenly removed. The mechanism by which an administrator adds - an entry with a reused Unique Identifier is outside the scope of the - X.500 and LDAP standards since the Unique Identifier of an entry is - not a user modifiable attribute. Note that from the perspective of a - consumer directory server of a partial area of replication, an entry - may appear to be removed and added several times because - modifications to the entry change whether the entry satisfies the - replication agreement specification for the area of replication. - - Additionally, a deletion record is kept for each of the recently - deleted entries (entry deletion records), attributes (attribute - deletion records), or attribute values (value deletion records). A - deletion record contains a CSN and asserts that the associated - directory object no longer existed at the particular time. - - 4.3 Replication Primitives - - Each update operation performed on an entry in a part of the DIT - subject to one or more replication agreements MUST be subsequently - reported as replication primitives to the replication partner - directory servers of those agreements. The collection of primitives - sent by a directory server to a replication partner will reflect both - the results of locally processed user update requests and also of - replicated updates received from other directory servers. A single - update operation will decompose into one or more primitives. - - Common to all update primitives is an entry identifier argument, uid, - containing the Unique Identifier of the target entry of the change, - and a CSN argument, csn, to indicate the time of the change. In the - case of adding a new entry, the Unique Identifier for the entry is - allocated by the directory server in the course of processing the - operation. Additional arguments are present depending on the type of - replication primitive. - - - - -Legg & Payne Expires 29 December 2000 [Page 4] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - The p-add-entry(uid, csn, superior, rdn) primitive is used to - describe the addition of a new entry with minimal contents. The - superior argument contains the Unique Identifier of the immediate - superior entry of the added entry. The rdn argument contains the - Relative Distinguished Name of the added entry. - - The p-move-entry(uid, csn, superior) primitive is used to describe - the moving of an entry to a new immediate superior in the DIT. The - superior argument contains the Unique Identifier of the new superior - entry. - - The p-rename-entry(uid, csn, rdn) primitive is used to describe a - change to the Relative Distinguished Name of an entry. The rdn - argument contains the new RDN for the entry. - - The p-remove-entry(uid, csn) primitive is used to describe the - removal of an entry. - - The p-add-attribute-value(uid, csn, type, value) primitive is used to - describe the addition of a single attribute value to an entry. The - type argument contains the attribute type of the value and the value - argument contains the attribute value. - - The p-remove-attribute-value(uid, csn, type, value) primitive is used - to describe the removal of a single attribute value from an entry. - The type argument contains the attribute type of the value and the - value argument contains the attribute value. - - The p-remove-attribute(uid, csn, type) primitive is used to describe - the removal of all values of an attribute from an entry. The type - argument contains the removed attribute type. - - These primitives reflect the intended final state of an update - operation rather than the specific changes required to achieve that - state. - - 4.4 Lost & Found - - As a result of conflicting updates at two or more master directory - servers, an entry may be left with a reference to a non-existent - superior entry. Such an entry is called an orphaned entry. When - this situation arises, the directory server creates a glue entry for - the missing superior entry. This glue entry is made a subordinate of - the specially nominated Lost & Found entry and the orphaned entry - becomes a subordinate of the glue superior entry (see Section 5.3.2). - Entries that exist in the Lost & Found subtree can still be modified - by actions of the replication protocol since entries are identified - by Unique Identifiers in the protocol, independent of their - - - -Legg & Payne Expires 29 December 2000 [Page 5] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - positioning in the global DIT. - - Entries will also be explicitly moved to become immediate - subordinates of the Lost & Found entry to prevent the formation of a - loop in the superior-subordinate relationships in the DIT. This - situation can only arise through conflicting move entry operations at - two or more master directory servers. - - Entries that exist under the Lost & Found entry are able to be - returned to a suitable position in the DIT by an administrator or - user with appropriate access rights. - - 5. Replication Procedures - - The procedures defined in this section ensure the consistent and - correct application of the results of DAP, LDAP or DSP operations - across all replicating directory servers. - - 5.1 Processing LDAP, DAP or DSP Operations on the DIT - - A successful DAP, LDAP or DSP operation applied to a part of the DIT - subject to a replication agreement will create or replace one or more - CSNs on an entry or its contents, and create zero, one or more - deletion records referencing the entry or its contents. The CSNs and - deletion records generated from an operation are atomic with that - operation. That is, either the operation succeeds, the CSNs are - revised and the deletion records are stored, or the operation fails, - no CSNs are revised and no deletion records are stored. In all - cases, all current error conditions (i.e. reasons for rejecting an - LDAP, DAP or DSP update operation) remain. - - At some later time, possibly immediately following the update or - concurrently with it, the CSNs on entry contents and deletion records - are used to generate the replication primitives that will report the - update to other directory servers via a replication session. - - All the CSNs generated from a single update operation MUST use the - same time, change count and Replica Identifier. The modification - number is permitted to vary but MUST be assigned such that when the - CSNs resulting from the operation, including those in the deletion - records, are compared to the CSNs resulting from any other operation - they are all strictly greater than or all strictly less than those - other CSNs (i.e. in a global CSN ordering of the primitives - resulting from all operations the primitives of each operation MUST - be contiguous in that ordering). In order for the update to be - consistently applied when replicated to other directory servers the - CSNs generated during that update must generally be greater than any - pre-existing CSNs on the updated entry's contents. It is expected - - - -Legg & Payne Expires 29 December 2000 [Page 6] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - that directory servers will normally use the current time according - to their system clocks in generating the CSNs for an operation. - However in an environment where directory server clocks are not - necessarily synchronized the current time may be older than existing - CSNs on entry contents. The constraints the new CSNs MUST satisfy - with respect to pre-existing CSNs on entry data are covered in the - sections on each type of update operation. The Update Reconciliation - Procedures allow a directory server to generate CSNs in advance of - its current time to satisfy the constraints and proceed with the - update. - - The LDUP Update Vector mechanism imposes the additional constraint - that the CSN generated for an update operation MUST also be greater - than the highest CSN generated by the directory server that has - already been seen by any other directory server. An implementation - that generates successively greater CSNs for each operation will - satisfy this constraint. - - The following sections describe the additional actions carried out in - processing each standard type of update operation in order to support - replication. If a directory server implementation supports other - non-standard update operations or alternative non-directory update - protocols then, in so far as these operations alter replicated - directory data, the implementation MUST generate and apply CSNs and - deletion records that accurately reflect any change. - - A directory server implementation may also perform implicit updates - in response to user update requests, e.g. to maintain the referential - integrity of distinguished names. Appropriate CSNs and deletion - records for these changes MUST also be generated. - - A detailed description of the replication processing for these other - types of update is beyond the scope of this document. - - - 5.1.1 Add Entry - - The LDAP Add operation [LDAPv3] or DAP addEntry operation [X511] is - used to add a leaf entry to the DIT. A successful request will - generate a CSN for the entry. The CSN on the entry's RDN, the CSN on - the entry's superior reference, and the CSN on each distinguished and - non-distinguished value added to the entry by the add entry operation - are set to this same value. The affected values include any - operational attribute values automatically generated by the directory - server, e.g. creatorsName and createTimestamp. Note that the value - of the createTimestamp attribute does not necessarily correspond to - the time component of the CSN associated with that value. - - - - -Legg & Payne Expires 29 December 2000 [Page 7] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - The Unique Identifier generated for an entry created by a user - request is required to be globally unique for all time, so there - ought not be a pre-existing entry deletion record for the same Unique - Identifier. However it is recognized that, in practice, directory - administrators may need to restore a deleted entry using its original - Unique Identifier (the mechanism used to achieve this is undefined - and outside the scope of this specification). In this case the CSN - for the entry MUST be generated such that it is greater than or equal - to the CSN of any existing entry, attribute or value deletion - records, and greater than any of the CSNs contained in an existing - glue entry, for the same Unique Identifier. - - 5.1.2 Remove Entry - - The LDAP Delete operation [LDAPv3] or DAP removeEntry operation - [X511] is used to remove a leaf entry from the DIT. If the request - succeeds then an entry deletion record is stored containing the - Unique Identifier of the removed entry. The CSN for the entry - deletion record MUST be generated such that it is greater than the - entry CSN of the removed entry. - - 5.1.3 Modify Entry - - The LDAP Modify operation (ModifyRequest) [LDAPv3] or DAP modifyEntry - operation [X511] is used to perform a series of one or more - modifications to an entry. If the request succeeds then zero, one or - more new values with CSNs are added to the entry contents, and zero, - one or more value or attribute deletion records are stored. - - The modifications described by the modification argument of the LDAP - ModifyRequest have the following additional effects: - - a) The add alternative associates a CSN with each of the added - attribute values. - - b) The delete alternative with no listed values generates an - attribute deletion record for the removed attribute type. - - c) The delete alternative with listed values generates a value - deletion record for each of the removed values. - - d) The replace alternative first generates an attribute deletion - record for the removed attribute type. A CSN is then associated - with each of the added values. - - The modifications described by the changes argument of the X.500 - modifyEntry operation have the following additional effects: - - - - -Legg & Payne Expires 29 December 2000 [Page 8] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - a) The addAttribute and addValues alternatives associate a CSN - with each of the added attribute values. These two alternatives - are equivalent from the point of view of URP since there is no CSN - associated specifically with the attribute type. - - b) The removeAttribute alternative generates an attribute deletion - record for the removed attribute type. - - c) The removeValues alternative generates a value deletion record - for each of the removed values. - - d) The alterValues alternative first generates a value deletion - record for each of the old values. Secondly, a CSN is associated - with each of the new values. - - e) The resetValues alternative generates a value deletion record - for each value actually removed. - - A successful ModifyRequest or modifyEntry operation will also result - in changes to operational attributes of the entry. Like the explicit - modifications to user attributes, CSNs are given to new operational - attribute values and deletion records are stored for operational - attribute values that are removed. The processing in each case - depends on the semantics of the particular operational attribute type - and can be deduced by considering an equivalent explicit modification - request. In particular, the revision of the modifyTimestamp and - modifiersName attributes is treated like the ModifyRequest replace - alternative. Note that the value of the modifyTimestamp attribute - does not necessarily correspond to the time component of the CSN - associated with that value. The entryUUID operational attribute - SHALL NOT be modified. Consequently attribute and value deletion - records for the entryUUID attribute type are never generated. - - The CSNs generated by a modify operation MUST be greater than the CSN - of any pre-existing attribute value that is removed, greater than or - equal to the CSN of any pre-existing attribute deletion record or - value deletion record applying to an added attribute value, and - greater than or equal to the CSN of the entry. - - A further constraint applies to the modification number component of - the CSNs generated by a single modify operation. The CSN generated - for an added attribute value MUST be greater than or equal to the CSN - on any applicable value deletion record or attribute deletion record - already created by this same operation. This constraint is satisfied - if the same modification number is used in all the CSNs generated by - a single modify operation, or if the CSNs generated as the sequence - of modifications in the operation are applied in order use - monotonically increasing modification numbers. The modification - - - -Legg & Payne Expires 29 December 2000 [Page 9] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - numbers need not be consecutive in this case. - - Whenever a new value is added to the entry contents any value - deletion record for the same entry, attribute type and attribute - value MAY be discarded. - - 5.1.4 Modify DN - - The LDAP Modify DN operation [LDAPv3] and DAP modifyDN operation - [X511] are used to change the Relative Distinguished Name of an entry - and/or to move an entry to a new superior in the DIT. If the entry - is moved to a new superior in the DIT then the CSN on the entry's - superior reference is replaced. If the entry's RDN is changed then - the CSN on the entry's RDN is replaced. A value deletion record is - stored for each of the formally distinguished attribute values - removed from the entry as a consequence of the deleteOldRDN parameter - (modifyDN) or deleteoldrdn parameter (ModifyDNRequest) being set to - true. An entryUUID attribute value that is made non-distinguished - SHALL NOT be removed from the entry regardless of the deleteOldRDN or - deleteoldrdn flag and SHALL NOT have a corresponding value deletion - record. - - If the CSN on the entry's superior reference is revised then the new - value MUST be greater than the previous value. If the CSN on the - entry's RDN is revised then the new value MUST be greater than the - previous value of the CSN on the RDN. The CSNs for any value - deletion records MUST be greater than the CSNs on the removed - attribute values. - - 5.2 Generating Replication Primitives - - Each time a replication session is invoked, the supplier directory - server generates and sends replication primitives for updates known - to the supplier but not yet known to the consumer directory server. - The supplier uses the Update Vector of the consumer to determine what - to send. Conceptually, the supplier scans all the glue and non-glue - entries and deletion records covered by the replication agreement - with the consumer and generates primitives where the CSNs held by the - supplier are greater than the CSN for the corresponding identified - replica in the consumer's Update Vector. No replication primitives - are generated for entries or entry contents that are outside the - scope of the replication agreement. - - A p-add-entry primitive is generated for each entry whose entry CSN - is greater than the Update Vector CSN for the same replica. The - superior argument of the p-add-entry primitive contains the Unique - Identifier of the immediate superior entry of the added entry. The - rdn argument of the p-add-entry primitive contains the Relative - - - -Legg & Payne Expires 29 December 2000 [Page 10] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - Distinguished Name of the created entry except that the value of the - entryUUID attribute, if distinguished, is always omitted from the - RDN. The superior and rdn arguments are provided even if the CSN on - the superior reference or the RDN are greater than the CSN on the - entry. - - A p-add-attribute-value primitive is generated for each distinguished - value that has a CSN greater than the Update Vector CSN for the same - replica and greater than the CSN on the RDN of its entry. A p-add- - attribute-value primitive is generated for each non-distinguished - value that has a CSN greater than the Update Vector CSN for the same - replica. The values of operational attributes are treated in the - same way as the values of user attributes. The p-add-attribute-value - primitive uses the CSN of the corresponding value. There are no - separate primitives generated for the distinguished values that have - the same CSN as the CSN on their entry's RDN. - - If the CSN on an entry's RDN is greater than the Update Vector CSN - for the same replica and greater than the CSN on the entry then a p- - rename-entry primitive is generated. The CSN for this primitive is - the CSN on the entry's RDN and the rdn argument contains the Relative - Distinguished Name of the entry. - - If the CSN on the entry's superior reference is greater than the - Update Vector CSN for the same replica and greater than the CSN on - the entry then a p-move-entry primitive is generated. The CSN for - this primitive is the CSN on the entry's superior reference and the - superior argument contains the Unique Identifier of the immediate - superior entry. - - A p-remove-attribute-value primitive is generated for each value - deletion record having a CSN greater than the Update Vector CSN for - the same replica. The primitive uses exactly the same arguments as - the value deletion record. - - A p-remove-attribute primitive is generated for each attribute - deletion record having a CSN greater than the Update Vector CSN for - the same replica. The primitive uses exactly the same arguments as - the attribute deletion record. - - A p-remove-entry primitive is generated for each entry deletion - record having a CSN greater than the Update Vector CSN for the same - replica. The primitive uses exactly the same arguments as the entry - deletion record. - - Rather than scanning the DIT, an implementation MAY choose to - generate replication primitives as the user update requests are being - processed and put these primitives into a replication log in - - - -Legg & Payne Expires 29 December 2000 [Page 11] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - preparation for sending during the next replication session. Any - replication primitives generated from an operation in this way MUST - be atomic with that operation. That is, either the operation - succeeds, and primitives are added to the replication log, or the - operation fails, and no primitives are added to the log. The - replication log MAY be filtered prior to sending to eliminate any - primitives that are superseded by later primitives in the log, and to - eliminate any primitives having CSNs less than or equal to the - relevant CSNs contained in a consumer directory server's Update - Vector. - - In a log based implementation, the p-add-attribute-value primitive - supersedes a p-remove-attribute-value primitive for the same entry, - attribute type, attribute value and equal or older CSN. It - supersedes another p-add-attribute-value primitive for the same - entry, attribute type, attribute value and older CSN. - - The p-remove-attribute-value primitive supersedes a p-add-attribute- - value primitive for the same entry, attribute type, attribute value - and older CSN. It supersedes another p-remove-attribute-value - primitive for the same entry, attribute type, attribute value and - equal or older CSN. - - The p-remove-attribute primitive supersedes a p-add-attribute-value - primitive for the same entry, attribute type and older CSN. It - supersedes a p-remove-attribute-value or another p-remove-attribute - primitive for the same entry, attribute type and equal or older CSN. - - The p-remove-entry primitive supersedes a p-add-attribute-value, p- - add-entry, p-move-entry or p-rename-entry primitive for the same - entry and older CSN. It supersedes a p-remove-attribute-value or p- - remove-attribute or another p-remove-entry primitive for the same - entry and equal or older CSN. - - The p-move-entry primitive supersedes another p-move-entry primitive - for the same entry and older CSN. - - 5.3 Processing Replication Primitives on the DIT - - Each replication primitive received from another directory server - during a replication session that is within the scope of the - replication agreement is processed against the DIT. Replication - primitives outside the scope of the replication agreement are - rejected. - - This section defines some commonly used sub-procedures and the - algorithms for processing each of the primitives. These algorithms - are not intended to be implemented verbatim but instead describe the - - - -Legg & Payne Expires 29 December 2000 [Page 12] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - behaviour an LDUP implementation MUST exhibit externally. - Alternative equivalent processing logic is permitted. - - Components of primitives, entries, attributes and values are - referenced with the `.' operator. In particular the notation X.csn - refers to the CSN of the directory object X. The operators, < and > - when applied to CSNs, use the convention of CSNs becoming greater - with the progression of time, so older CSNs are less than younger - CSNs. In the case where the CSN for object X has been discarded - through the purging mechanism, X.csn is assumed to have the least - possible CSN value. In some of the procedures a CSN will be - explicitly purged. An implementation MAY instead keep the CSN but - set it to some value that is old enough for it to be eligible for - purging (e.g. the least possible CSN value) without affecting the - correctness of the procedures. - - For an entry, E, the notation E.rdn refers to the entry's Relative - Distinguished Name, E.dn refers to the entry's Distinguished Name, - and E.superior refers to the Unique Identifier of the entry's - superior in the DIT. - - 5.3.1 Saving Deletion Records - - It is necessary for a directory server to store deletion records to - remember that some entry, attribute or attribute value has been - deleted, for a period after the processing of the update operation or - replication primitive causing the deletion. - - Value deletion records have the same parameters as the p-remove- - attribute-value primitive. The StoreValueDeletion procedure creates - a value deletion record from the actual arguments and stores it for - later access by the various primitive processing procedures. When an - attribute value is added to an entry, a value deletion record for the - same entry, attribute type and value, and with an older CSN, MAY be - discarded. - - Attribute deletion records have the same parameters as the p-remove- - attribute primitive. The StoreAttributeDeletion procedure creates an - attribute deletion record from the actual arguments and stores it for - later access. When an attribute deletion record is stored any value - deletion records for the same entry and attribute type, and with - equal or older CSNs, MAY be discarded. - - Entry deletion records have the same parameters as the p-remove-entry - primitive. The StoreEntryDeletion procedure creates an entry - deletion record from the actual arguments and stores it for later - access. When an entry deletion record is stored any value deletion - records and attribute deletion records for the same entry, and with - - - -Legg & Payne Expires 29 December 2000 [Page 13] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - equal or older CSNs, MAY be discarded. - - Since the deletion records have the same components as their - associated remove primitives an implementation MAY choose to use the - same internal structures for both. - - 5.3.2 Glue Entries - - Entries are permitted to be re-added and this can lead to situations - where applicable primitives are received in the period after an entry - is removed but before the arrival of the notification of it being - re-added. In these cases a glue entry is created for the Unique - Identifier to preserve relevant updates in the event that a p-add- - entry primitive with an older CSN is later received for the same - entry. A glue entry is upgraded to a normal entry by a subsequent - p-add-entry primitive. - - A glue entry with no subordinate entries and containing only CSNs (on - itself or its component parts) that are eligible to be purged MAY be - removed. A glue entry is discarded if its contents are completely - superseded by another p-remove-entry primitive. - - The CreateGlueEntry function is called when required to create a glue - entry as a subordinate of Lost & Found. CreateGlueEntry takes a - single parameter which is the Unique Identifier for the glue entry. - The Unique Identifier, in the form of the entryUUID attribute, also - becomes the RDN for the glue entry. No CSNs are associated with the - entry, the entry's superior reference, or the entry's name (or - equivalently they are set to the least possible CSN value). - - 5.3.3 Generating Change Sequence Numbers - - There are circumstances where conflicts arise in the processing of a - replication primitive. It is necessary in these cases for the - directory server processing the primitives to make corrective changes - and emit additional primitives to ensure that all other directory - servers reach the same consistent state. The GenerateNextCSN - function is used to obtain a CSN for the corrective change. An - implementation that generates replication primitives as the user - update requests are being processed and puts them into a replication - log MUST take the additional step of creating a primitive to convey - the corrective change to other directory servers. Implementations - that generate primitives by scanning entries will pick up the - corrective change automatically. - - As is the case for CSNs generated from DAP, DSP or LDAP operations, - the CSN for the corrective change is typically generated from the - current clock time of the directory server. The conditions imposed - - - -Legg & Payne Expires 29 December 2000 [Page 14] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - for the correct operation of the LDUP Update Vector MUST also be - satisfied. - - GenerateNextCSN takes a single CSN parameter. In addition to all - other conditions, the CSN generated by the function MUST be greater - than this parameter. Since the CSN parameter passed to - GenerateNextCSN is always an actual CSN from some directory object - stored in the local directory server, an implementation MAY choose to - allocate CSNs from an incrementing internal CSN register that is - reset after each replication session to a value greater than the - largest CSN seen so far, and thereby be safely able to disregard the - parameter to GenerateNextCSN. - - 5.3.4 Comparison of Attribute Values - - Values in primitives, in deletion records or in entries are compared - using the equality matching rule for the associated attribute type - where that type is permitted to be multi-valued. This means that two - values that are considered equal may nonetheless have minor - differences. For example, two commonName values may be equal, but - use different letter case and have different numbers of leading or - trailing spaces. Whenever a CSN for some value is refreshed the - value is also refreshed using the exact value from the primitive so - that all directory servers use exactly the same representation for - the value. - - Compared values for a single-valued attribute type are all considered - to be equal even though they may be significantly different according - to that attribute type's equality matching rule. In effect the - equality operator, `=', in the following procedures is - unconditionally true when used to compare values of a single-valued - attribute type. Whenever a CSN for the value of a single-valued - attribute is refreshed the value is also refreshed using the value - from the primitive. One significant consequence is that an entry - whose RDN contains a value of a single-valued attribute type is - effectively renamed by a p-add-attribute-value primitive with a more - recent value for the attribute type. - - A value in an entry that is replaced by the exact representation from - a primitive retains its distinguished or non-distinguished status. - This includes replaced values of single-valued attribute types. - - 5.3.5 Entry Naming - - Independent changes at two or more directory servers can lead to the - situation of two distinct entries having the same name. The - procedure, CheckUniqueness(E, S, R), takes an entry and determines - whether it is uniquely named. If not, it disambiguates the names of - - - -Legg & Payne Expires 29 December 2000 [Page 15] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - the entries by adding the Unique Identifier (i.e. the entryUUID - attribute) of each of the conflicting entries to their own RDN. - - The procedure CheckUniqueness is called in each circumstance where - the Relative Distinguished Name of an entry might conflict with - another entry, either because the entry has been renamed or because - it has been moved to a new superior. An entry can be renamed - directly by a p-rename-entry primitive, or as a side-effect of other - primitives causing changes to distinguished values. While each move - or rename of an entry potentially causes a conflict with some other - entry already having the new Distinguished Name, it also potentially - removes a previous conflict on the old Distinguished Name. To enable - the CheckUniqueness function to remove the Unique Identifier from an - entry's RDN when it is no longer needed, the old name for an entry is - passed through the second and third parameters. The parameter, S, is - the Unique Identifier of the old superior entry of E, and the - parameter, R, is the old RDN of E. CheckUniqueness ignores - distinguished entryUUID values when comparing entry RDNs. The - function BaseRDN(rdn) returns its argument minus any distinguished - entryUUID values, to support these comparisons. - - CheckUniqueness(E, S, R) - { - make E.uid non-distinguished - IF there exists exactly one subordinate entry, C, of S - where BaseRDN(C.rdn) = BaseRDN(R) - make C.uid non-distinguished - IF E.rdn is empty - make C.uid distinguished - ELSE IF there exists a subordinate entry, C, of E.superior - where E <> C AND BaseRDN(C.rdn) = BaseRDN(E.rdn) - { - make C.uid distinguished - make E.uid distinguished - } - } - - Because updates are performed in isolation at multiple directory - servers in a multimaster configuration it is possible to encounter a - situation where there is a request to delete a distinguished value in - an entry. The recommended practice in these circumstances is to - remove the distinguished value and call CheckUniqueness to correct - any resulting name conflicts. An implementation MAY instead reassert - the existence of the distinguished value with a more recent CSN to - avoid altering the entry's RDN. This option is only available to - updatable replicas. Read-only replicas MUST remove the distinguished - value. The function ProtectDistinguished() returns true for an - updatable part of the DIT in a directory server that implements this - - - -Legg & Payne Expires 29 December 2000 [Page 16] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - option, and false otherwise. directory servers exercising this - option MUST generate a p-add-attribute-value primitive so that other - directory servers are guaranteed to also reassert the distinguished - value. Directory servers that implement the option will correctly - interwork with servers that do not. - - The primitives p-add-entry and p-rename-entry contain common elements - that are applied to the Relative Distinguished Name of an entry in - the same way. This common processing is described in the RenameEntry - procedure. The parameters to this procedure are the entry, E, and - the p-add-entry or p-rename-entry primitive specifying the new RDN. - The procedure assumes that the entry does not currently contain any - distinguished values. It is the responsibility of the calling - procedure to first reset any pre-existing distinguished values to - non-distinguished. The procedure then resets the CSNs and sets the - distinguished flags for existing values and adds distinguished values - if necessary. The CSN for the entry's RDN, as distinct from the CSNs - on each of the distinguished values making up the RDN, is also set. - - RenameEntry(E, P) - { - FOREACH AttributeTypeAndValue, N, in P.rdn - IF there exists an attribute value, V, in E of type N.type - where V = N.value - { - IF P.csn > V.csn - { - replace V with N.value if they are not identical - V.csn := P.csn - } - make V distinguished - } - ELSE IF ProtectDistinguished() - { - V := N.value - add V to E as a distinguished value - V.csn := P.csn - FOREACH attribute deletion record (uid, type, csn) - where (uid = P.uid AND type = N.type) - IF csn > V.csn - V.csn := csn - FOREACH value deletion record (uid, type, value, csn) - where (uid = P.uid AND type = N.type AND value = N.value) - IF csn > V.csn - V.csn := csn - V.csn := GenerateNextCSN(V.csn) - } - ELSE IF no attribute deletion record (uid, type, csn) exists - - - -Legg & Payne Expires 29 December 2000 [Page 17] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - where (uid = P.uid AND type = N.type AND csn > P.csn) - AND no value deletion record (uid, type, value, csn) exists - where (uid = P.uid AND type = N.type AND - value = N.value AND csn > P.csn) - { - V := N.value - add V to E as a distinguished value - V.csn := P.csn - } - E.rdn.csn := P.csn - } - - - 5.3.6 Processing Add Attribute Value Primitive - - This section details the algorithm for processing the p-add- - attribute-value (P.uid, P.type, P.value, P.csn) primitive, which - describes the addition of a single attribute value. If P.type is the - entryUUID attribute type then the primitive MUST be rejected. - - IF no value deletion record (uid, type, value, csn) exists where - (uid = P.uid AND type = P.type - AND value = P.value AND csn > P.csn) - AND no attribute deletion record (uid, type, csn) exists where - (uid = P.uid and type = P.type AND csn > P.csn) - AND no entry deletion record (uid, csn) exists where - (uid = P.uid AND csn > P.csn) - { - IF entry, E, with uid = P.uid does not exist - E := CreateGlueEntry(P.uid) - IF P.csn >= E.csn - IF attribute value V, of type P.type - where V = P.value exists in E - { - IF P.csn > V.csn - { - V.csn := P.csn - R := E.rdn - replace V with P.value if they are not identical - IF V is distinguished - AND P.type is a single-valued attribute type - CheckUniqueness(E, E.superior, R) - } - } - ELSE - { - V := P.value - Add V to E as a non-distinguished attribute value - - - -Legg & Payne Expires 29 December 2000 [Page 18] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - V.csn := P.csn - } - } - - - 5.3.7 Processing Remove Attribute Value Primitive - - This section details the algorithm for processing the p-remove- - attribute-value (P.uid, P.type, P.value, P.csn) primitive, which - describes the removal of a single attribute value. If P.type is the - entryUUID attribute type then the primitive MUST be rejected. - - IF no value deletion record (uid, type, value, csn) exists - where (uid = P.uid AND type = P.type AND - value = P.value AND csn >= P.csn) - AND - no attribute deletion record (uid, type, csn) exists - where (uid = P.uid AND type = P.type AND csn >= P.csn) - AND - no entry deletion record (uid, csn) exists - where (uid = P.uid AND csn >= P.csn) - IF entry, E, with uid = P.uid exists - { - IF P.csn > E.csn - IF attribute value, V, of P.type - where V = P.value, exists in E - { - IF P.csn > V.csn - IF V is distinguished - IF ProtectDistinguished() - V.csn := GenerateNextCSN(P.csn) - ELSE - { - R := E.rdn - remove value V - CheckUniqueness(E, E.superior, R) - StoreValueDeletion (P.uid, P.type, P.value, P.csn) - } - ELSE - { - remove value V - StoreValueDeletion (P.uid, P.type, P.value, P.csn) - } - } - ELSE - StoreValueDeletion (P.uid, P.type, P.value, P.csn) - } - ELSE - - - -Legg & Payne Expires 29 December 2000 [Page 19] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - StoreValueDeletion (P.uid, P.type, P.value, P.csn) - - The presence of a younger deletion record for the entry, attribute or - value provides a convenient test for whether the p-remove-attribute- - value primitive needs to be processed at all. If the value exists to - be removed then there cannot be a deletion record affecting it that - has a younger CSN. If there is a younger deletion record than the - primitive then there cannot be an older value to remove. - - - 5.3.8 Processing Remove Attribute Primitive - - This section details the algorithm for processing the p-remove- - attribute (P.uid, P.type, P.csn) primitive, which describes the - removal of all attribute values of P.type. If P.type is the - entryUUID attribute type then the primitive MUST be rejected. - - IF no attribute deletion record (uid, type, csn) exists - where (uid = P.uid AND type = P.type AND csn >= P.csn) - AND no entry deletion record (uid, csn) exists where - (uid = P.uid AND csn >= P.csn) - IF entry, E, with uid = P.uid exists - { - IF P.csn > E.csn - { - FOREACH attribute value, V, of type P.type in E (if any) - IF P.csn > V.csn - IF V is distinguished - IF ProtectDistinguished() - V.csn := GenerateNextCSN(P.csn) - ELSE - { - R := E.rdn - remove value V - CheckUniqueness(E, E.superior, R) - } - ELSE - remove value V - StoreAttributeDeletion (P.uid, P.type, P.csn) - } - } - ELSE - StoreAttributeDeletion (P.uid, P.type, P.csn) - - - 5.3.9 Processing Add Entry Primitive - - This section details the algorithm for processing the p-add-entry - - - -Legg & Payne Expires 29 December 2000 [Page 20] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - (P.uid, P.superior, P.rdn, P.csn) primitive, which describes the - addition of an entry. The CSN on an entry records the time of the - latest p-add-entry primitive for the Unique Identifier. In normal - circumstances there will only ever be one p-add-entry primitive - associated with an entry. The entry CSN MAY be discarded when it - becomes eligible to be purged according to the Purge Vector. - - IF no entry deletion record (uid, csn) exists where - (uid = P.uid AND csn > P.csn) - IF entry, E, with uid = P.uid exists - { - IF P.csn > E.csn - { - R := E.rdn - S := E.superior - E.csn := P.csn - FOREACH attribute type, T, in E, except entryUUID - FOREACH attribute value, V, of type T - IF V.csn < P.csn - remove value V - CheckUniqueness(E, S, R) - process P according to - p-rename-entry(P.uid, P.rdn, P.csn) - process P according to - p-move-entry(P.uid, P.superior, P.csn) - } - } - ELSE - { - create entry E - E.csn := P.csn - E.uid := P.uid - E.uid.csn := P.csn - IF an entry with uid = P.superior does not exist - CreateGlueEntry(P.superior) - E.superior = P.superior - E.superior.csn := P.csn - RenameEntry(E, P) - CheckUniqueness(E, E.superior, E.rdn) - } - - - 5.3.10 Processing Remove Entry Primitive - - This section details the algorithm for processing the p-remove-entry - (P.uid, P.csn) primitive, which describes the removal of an entry. - If the target entry has attribute values with CSNs greater than the - primitive's CSN, a superior reference with a greater CSN, or if it - - - -Legg & Payne Expires 29 December 2000 [Page 21] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - has any subordinate entries, it becomes a glue entry instead of being - removed. It is also moved to Lost & Found, unless it has a CSN for - its superior reference that is greater than the CSN of the p-remove- - entry. - - IF no entry deletion record (uid, csn) exists - where (uid = P.uid AND csn >= P.csn) - IF entry, E, with uid = P.uid exists - { - IF P.csn > E.csn - { - IF E.superior.csn >= P.csn - OR any value, V, with csn >= P.csn exists - OR E has subordinates - { - R := E.rdn - S := E.superior - make E a glue entry - purge E.csn - IF E.superior.csn < P.csn - { - E.superior := LOST_AND_FOUND - purge E.superior.csn - } - IF E.rdn.csn < P.csn - purge E.rdn.csn - FOREACH attribute type, T, in E, except entryUUID - FOREACH attribute value, V, of type T - IF V.csn < P.csn - remove value V - CheckUniqueness(E, S, R) - } - ELSE - remove entry E - StoreEntryDeletion (P.uid, P.csn) - } - } - ELSE - StoreEntryDeletion (P.uid, P.csn) - - - 5.3.11 Processing Move Entry Primitive - - This section details the algorithm for processing the p-move-entry - (P.uid, P.superior, P.csn) primitive, which describes the moving of - an entry to a new immediate superior in the DIT. If the new superior - specified by the primitive does not exist, or is a direct or indirect - subordinate of the entry being moved, then the entry is moved to Lost - - - -Legg & Payne Expires 29 December 2000 [Page 22] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - & Found instead. - - IF no entry deletion record (uid, csn) exists - where (uid = P.uid AND csn > P.csn) - { - IF entry, E, with uid = P.uid does not exist - E := CreateGlueEntry(P.uid) - IF P.csn > E.superior.csn - { - R := E.rdn - O := E.superior - IF entry, S, with uid = P.superior does not exist - S := CreateGlueEntry(P.superior) - IF S is not in the subtree of E - { - E.superior := P.superior - E.superior.csn = P.csn - } - ELSE - { - E.superior := LOST_AND_FOUND; - E.superior.csn := GenerateNextCSN(P.csn) - } - CheckUniqueness(E, O, R) - } - } - - - 5.3.12 Processing Rename Entry Primitive - - This section details the algorithm for processing the p-rename-entry - (P.uid, P.rdn, P.csn) primitive, which describes a change to the - Relative Distinguished Name of an entry. A p-rename-entry primitive - that is older than current name of an entry is not simply ignored - since it may contain attribute values that would have been added to - the entry had the primitives arrived in CSN order. These extra - values would now be non-distinguished. - - IF no entry deletion record (uid, csn) exists - where (uid = P.uid AND csn >= P.csn) - { - IF entry, E, with uid = P.uid does not exist - E := CreateGlueEntry(P.uid) - IF P.csn > E.rdn.csn - { - R := E.rdn - FOREACH distinguished attribute value, V, in entry E - make V non-distinguished - - - -Legg & Payne Expires 29 December 2000 [Page 23] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - RenameEntry(E, P) - CheckUniqueness(E, E.superior, R) - } - ELSE - FOREACH AttributeTypeAndValue, N, in P.rdn - { - IF there exists an attribute value, V, in E of type - N.type AND V = N.value - { - IF P.csn > V.csn - { - replace V with N.value if they are not identical - V.csn := P.csn - } - } - ELSE - { - IF no value deletion record (uid, type, value, csn) - exists where (uid = P.uid AND type = N.type AND - value = N.value AND csn > P.csn) - AND - no attribute deletion record (uid, type, csn) - exists where (uid = P.uid AND type = N.type AND - csn > P.csn) - { - V := N.value - Add V to E - V.csn := P.csn - } - } - } - } - - - 6. Security Considerations - - The procedures described in this document are not subject to access - controls on the directory data items being modified. Specifically, - the update primitives received from a peer replica are applied - without regard for access controls. This is necessary so that access - control information can also be replicated. An LDUP enabled server - entering into a multi-master replication agreement with a peer server - is enabling joint authority and responsibility for some part of the - directory data. A replica must trust that the other replicas are - properly enforcing access controls on user update requests, but this - trust extends only as far as described by the replication agreements - currently in place. The replication agreement acts as a surrogate - for access controls between peer replicas. Replication primitives - - - -Legg & Payne Expires 29 December 2000 [Page 24] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - that are outside the scope of the agreement are rejected. - - Authentication of peer replica LDUP sessions and the security of the - exchange of replication primitives through the LDUP protocol are - outside the scope of this document and are described elsewhere. - - Simultaneous updates at different replicas can result in two entries, - corresponding to two different real world entities, having the same - distinguished name. The Update Reconciliation Procedures - disambiguate these two names by appending the respective Unique - Identifiers to the entries' RDNs. This action will disable any - access controls based on an entry's specific DN or RDN. Disabling - such an access control may have the effect of granting a permission - that was explicitly denied. Since a Unique Identifier is required to - be globally unique for all time, appending a Unique Identifier to the - RDN cannot unintentionally enable access controls applying to a - different real world entity. - - It is sufficient when disambiguating entry RDNs to append the UID to - only one of a pair of entries ending up with the same name. The - Update Reconciliation Procedures require both entries to have their - UID appended to minimize the chance that either entry will gain - permissions intended for the other. This is based on the assumption - that most access controls will grant permissions rather than deny - permissions. - - - 7. Acknowledgements - - The authors would like to thank Suellen Faulks and Tony Robertson - from Telstra and Mark Ennis from Adacel Technologies who contributed - to the design and verification of the procedures described in this - document. - - The authors would also like to thank the members of the LDUP - architecture group for their input into the refinement of the design. - - - 8. References - - [RFC2119] - S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119. - - [LDAPv3] - M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access - Protocol (v3)", RFC 2251, December 1997. - - [X500] - ITU-T Recommendation X.500 (08/97) | ISO/IEC 9594-1:1998, - Information Technology - Open Systems Interconnection - The - - - -Legg & Payne Expires 29 December 2000 [Page 25] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - Directory: Overview of concepts, models and services - - [X511] - ITU-T Recommendation X.511 (08/97) | ISO/IEC 9594-3:1998, - Information Technology - Open Systems Interconnection - The - Directory: Abstract service definition - - [BCP-11] - R. Hovey, S. Bradner, "The Organizations Involved in the - IETF Standards Process", BCP 11, RFC 2028, October 1996. - - - 9. Intellectual Property Notice - - 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. [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. - - - 10. Copyright Notice - - Copyright (C) The Internet Society (2000). 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 - - - -Legg & Payne Expires 29 December 2000 [Page 26] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - 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 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. - - - 11. Authors' Addresses - - Steven Legg - Adacel Technologies Ltd. - 250 Bay Street - Brighton, Victoria 3186 - AUSTRALIA - - Phone: +61 3 8530 7808 - Fax: +61 3 9596 2960 - EMail: steven.legg@adacel.com.au - - Alison Payne - Telstra - 21/242 Exhibition Street - Melbourne, Victoria 3000 - AUSTRALIA - - Phone: +61 3 9634 4628 - EMail: alison.payne@team.telstra.com - - 12. Appendix A - Changes From Previous Drafts - - 12.1 Changes in Draft 01 - - Some of the terminology has been changed to better align with the - terminology used in the LDUP architecture draft. - - Descriptions on the usage of CSNs have been revised to account for - the extra modification number component. - - The semantics of re-added entries has been simplified so that only - changes after the latest re-add are preserved instead of all those - after the earliest re-add. This eliminates the need for Addition - - - -Legg & Payne Expires 29 December 2000 [Page 27] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - CSNs in the entry. It is anticipated that new replication primitives - will be introduced to manage entries that come and go from partial - replicas instead of using p-add-entry and p-remove-entry. - - Orphaned entries are no longer moved directly to Lost & Found. - Instead a glue entry is created in Lost & Found for the missing - superior and the orphaned entry becomes a subordinate of that. This - change eliminates the need for explicit propagated primitives for - moving orphaned entries to Lost & Found. - - Glue entries have also been used as the mechanism for saving - primitives. There are no longer any references to saved primitives - though the functionality is still present. - - The procedures for processing received replication primitives have - been rearranged to follow a more consistent pattern where the - presence of deletion records is tested first. - - 12.2 Changes in Draft 02 - - Multimaster replication has been dropped as a work item for the next - edition of X.500 so references to the proposed X.500 multimaster - replication protocol have been removed. - - The treatment of distinguished values has been simplified. - Previously an attempt to remove a distinguished value caused the - value to be tagged distinguished-not-present. Now the distinguished - value is removed, and if necessary, the Unique Identifier is made - distinguished to avoid an empty RDN. Optionally, the value to be - removed can be reasserted by emitting an explicit p-add-attribute- - value primitive. - - The current draft is more implementation neutral. A replication log - no longer figures prominently in the specification. The previous - descriptions had the user updates generating replication primitives, - which in turn were used to determine the CSNs and deletion records. - The new descriptions have user updates generating CSNs and deletion - records and the primitives are subsequently generated from them. - - 12.3 Changes in Draft 03 - - The draft has been edited to make use of the key words "MUST", - "SHOULD", "MAY", etc. - - The treatment of server maintained operational attributes has been - clarified. - - An extra CheckUniqueness call has been added to the procedure for - - - -Legg & Payne Expires 29 December 2000 [Page 28] - -INTERNET-DRAFT LDUP Update Reconciliation Procedures June 29, 2000 - - - processing the p-add-entry primitive (Section 5.3.9) to cover the - case where an entry is re-added. A loop through all of the values of - an entry in the p-add-entry and p-remove-entry processing has been - altered to explicitly skip the entryUUID operational attribute. No - other changes have been made to the behaviour of the Update - Reconciliation Procedures from Draft 02. - - The list of references has been expanded. - - The Security Considerations section has been added. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Legg & Payne Expires 29 December 2000 [Page 29] - diff --git a/doc/drafts/draft-leach-uuids-guids-01.txt b/doc/drafts/draft-leach-uuids-guids-01.txt deleted file mode 100644 index d611d06fb0..0000000000 --- a/doc/drafts/draft-leach-uuids-guids-01.txt +++ /dev/null @@ -1,1708 +0,0 @@ - - - - - - -Network Working Group Paul J. Leach, Microsoft -INTERNET-DRAFT Rich Salz, Certco - -Category: Standards Track -Expires August 4, 1998 February 4, 1998 - - - - UUIDs and GUIDs - -STATUS OF THIS MEMO - - This document is an Internet-Draft. 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". - - To learn the current status of any Internet-Draft, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). - - Distribution of this document is unlimited. Please send comments to - the authors or the CIFS mailing list at . - Discussions of the mailing list are archived at - "-" "-" - "-" - - "-" - time_low = 4* - time_mid = 2* - time_high_and_version = 2* - clock_seq_and_reserved = - clock_seq_low = - node = 6* - hexDigit = - "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" - | "a" | "b" | "c" | "d" | "e" | "f" - | "A" | "B" | "C" | "D" | "E" | "F" - - The following is an example of the string representation of a UUID: - - f81d4fae-7dec-11d0-a765-00a0c91e6bf6 - -3.6 Comparing UUIDs for equality - - Consider each field of the UUID to be an unsigned integer as shown in - the table in section 3.1. Then, to compare a pair of UUIDs, - arithmetically compare the corresponding fields from each UUID in - order of significance and according to their data type. Two UUIDs are - equal if and only if all the corresponding fields are equal. - - - Leach, Salz expires Aug 1998 [Page 12] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - Note: as a practical matter, on many systems comparison of two UUIDs - for equality can be performed simply by comparing the 128 bits of - their in-memory representation considered as a 128 bit unsigned - integer. Here, it is presumed that by the time the in-memory - representation is obtained the appropriate byte-order - canonicalizations have been carried out. - - -3.7 Comparing UUIDs for relative order - - Two UUIDs allocated according to the same variant can also be ordered - lexicographically. For the UUID variant herein defined, the first of - two UUIDs follows the second if the most significant field in which - the UUIDs differ is greater for the first UUID. The first of a pair - of UUIDs precedes the second if the most significant field in which - the UUIDs differ is greater for the second UUID. - - -3.8 Byte order of UUIDs - - UUIDs may be transmitted in many different forms, some of which may - be dependent on the presentation or application protocol where the - UUID may be used. In such cases, the order, sizes and byte orders of - the UUIDs fields on the wire will depend on the relevant presentation - or application protocol. However, it is strongly RECOMMENDED that - the order of the fields conform with ordering set out in section 3.1 - above. Furthermore, the payload size of each field in the application - or presentation protocol MUST be large enough that no information - lost in the process of encoding them for transmission. - - In the absence of explicit application or presentation protocol - specification to the contrary, a UUID is encoded as a 128-bit object, - as follows: the fields are encoded as 16 octets, with the sizes and - order of the fields defined in section 3.1, and with each field - encoded with the Most Significant Byte first (also known as network - byte order). - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | time_low | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | time_mid | time_hi_and_version | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |clk_seq_hi_res | clk_seq_low | node (0-1) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | node (2-5) | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - - - - - Leach, Salz expires Aug 1998 [Page 13] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - -4. Node IDs when no IEEE 802 network card is available - - If a system wants to generate UUIDs but has no IEE 802 compliant - network card or other source of IEEE 802 addresses, then this section - describes how to generate one. - - The ideal solution is to obtain a 47 bit cryptographic quality random - number, and use it as the low 47 bits of the node ID, with the most - significant bit of the first octet of the node ID set to 1. This bit - is the unicast/multicast bit, which will never be set in IEEE 802 - addresses obtained from network cards; hence, there can never be a - conflict between UUIDs generated by machines with and without network - cards. - - If a system does not have a primitive to generate cryptographic - quality random numbers, then in most systems there are usually a - fairly large number of sources of randomness available from which one - can be generated. Such sources are system specific, but often - include: - - - the percent of memory in use - - the size of main memory in bytes - - the amount of free main memory in bytes - - the size of the paging or swap file in bytes - - free bytes of paging or swap file - - the total size of user virtual address space in bytes - - the total available user address space bytes - - the size of boot disk drive in bytes - - the free disk space on boot drive in bytes - - the current time - - the amount of time since the system booted - - the individual sizes of files in various system directories - - the creation, last read, and modification times of files in various - system directories - - the utilization factors of various system resources (heap, etc.) - - current mouse cursor position - - current caret position - - current number of running processes, threads - - handles or IDs of the desktop window and the active window - - the value of stack pointer of the caller - - the process and thread ID of caller - - various processor architecture specific performance counters - (instructions executed, cache misses, TLB misses) - - (Note that it precisely the above kinds of sources of randomness that - are used to seed cryptographic quality random number generators on - systems without special hardware for their construction.) - - In addition, items such as the computer's name and the name of the - operating system, while not strictly speaking random, will help - differentiate the results from those obtained by other systems. - - The exact algorithm to generate a node ID using these data is system - specific, because both the data available and the functions to obtain - - Leach, Salz expires Aug 1998 [Page 14] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - them are often very system specific. However, assuming that one can - concatenate all the values from the randomness sources into a buffer, - and that a cryptographic hash function such as MD5 [3] is available, - then any 6 bytes of the MD5 hash of the buffer, with the multicast - bit (the high bit of the first byte) set will be an appropriately - random node ID. - - Other hash functions, such as SHA-1 [4], can also be used. The only - requirement is that the result be suitably random _ in the sense that - the outputs from a set uniformly distributed inputs are themselves - uniformly distributed, and that a single bit change in the input can - be expected to cause half of the output bits to change. - - -5. Obtaining IEEE 802 addresses - - At the time of writing, the following URL - - http://standards.ieee.org/db/oui/forms/ - - contains information on how to obtain an IEEE 802 address block. At - the time of writing, the cost is $1250 US. - - -6. Security Considerations - - It should not be assumed that UUIDs are hard to guess; they should - not be used as capabilities. - - -7. Acknowledgements - - This document draws heavily on the OSF DCE specification for UUIDs. - Ted Ts'o provided helpful comments, especially on the byte ordering - section which we mostly plagiarized from a proposed wording he - supplied (all errors in that section are our responsibility, - however). - - -8. References - - [1] Lisa Zahn, et. al., Network Computing Architecture, Prentice - Hall, Englewood Cliffs, NJ, 1990 - - [2] DCE: Remote Procedure Call, Open Group CAE Specification C309 - ISBN 1-85912-041-5 28cm. 674p. pbk. 1,655g. 8/94 - - [3] R. Rivest, RFC 1321, "The MD5 Message-Digest Algorithm", - 04/16/1992. - - [4] NIST FIPS PUB 180-1, "Secure Hash Standard," National Institute - of Standards and Technology, U.S. Department of Commerce, DRAFT, May - 31, 1994. - - - Leach, Salz expires Aug 1998 [Page 15] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - -9. Authors' addresses - - Paul J. Leach - Microsoft - 1 Microsoft Way - Redmond, WA, 98052, U.S.A. - paulle@microsoft.com - Tel. 425 882 8080 - Fax. 425 936 7329 - - Rich Salz - 100 Cambridge Park Drive - Cambridge MA 02140 - salzr@certco.com - Tel. 617 499 4075 - Fax. 617 576 0019 - - -10. Notice - - 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. - - -11. Full Copyright Statement - - Copyright (C) The Internet Society 1997. 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 - - Leach, Salz expires Aug 1998 [Page 16] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - 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 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. - - - Appendix A _ UUID Sample Implementation - - This implementation consists of 5 files: uuid.h, uuid.c, sysdep.h, - sysdep.c and utest.c. The uuid.* files are the system independent - implementation of the UUID generation algorithms described above, - with all the optimizations described above except efficient state - sharing across processes included. The code has been tested on Linux - (Red Hat 4.0) with GCC (2.7.2), and Windows NT 4.0 with VC++ 5.0. The - code assumes 64 bit integer support, which makes it a lot clearer. - - All the following source files should be considered to have the - following copyright notice included: - - copyrt.h - - /* - ** Copyright (c) 1990- 1993, 1996 Open Software Foundation, Inc. - ** Copyright (c) 1989 by Hewlett-Packard Company, Palo Alto, Ca. & - ** Digital Equipment Corporation, Maynard, Mass. - ** Copyright (c) 1998 Microsoft. - ** To anyone who acknowledges that this file is provided "AS IS" - ** without any express or implied warranty: permission to use, copy, - ** modify, and distribute this file for any purpose is hereby - ** granted without fee, provided that the above copyright notices and - ** this notice appears in all source code copies, and that none of - ** the names of Open Software Foundation, Inc., Hewlett-Packard - ** Company, or Digital Equipment Corporation be used in advertising - ** or publicity pertaining to distribution of the software without - ** specific, written prior permission. Neither Open Software - ** Foundation, Inc., Hewlett-Packard Company, Microsoft, nor Digital - Equipment - ** Corporation makes any representations about the suitability of - ** this software for any purpose. - */ - - - uuid.h - - - Leach, Salz expires Aug 1998 [Page 17] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - #include "copyrt.h" - #undef uuid_t - typedef struct _uuid_t { - unsigned32 time_low; - unsigned16 time_mid; - unsigned16 time_hi_and_version; - unsigned8 clock_seq_hi_and_reserved; - unsigned8 clock_seq_low; - byte node[6]; - } uuid_t; - - /* uuid_create -- generate a UUID */ - int uuid_create(uuid_t * uuid); - - /* uuid_create_from_name -- create a UUID using a "name" - from a "name space" */ - void uuid_create_from_name( - uuid_t * uuid, /* resulting UUID */ - uuid_t nsid, /* UUID to serve as context, so identical - names from different name spaces generate - different UUIDs */ - void * name, /* the name from which to generate a UUID */ - int namelen /* the length of the name */ - ); - - /* uuid_compare -- Compare two UUID's "lexically" and return - -1 u1 is lexically before u2 - 0 u1 is equal to u2 - 1 u1 is lexically after u2 - Note: lexical ordering is not temporal ordering! - */ - int uuid_compare(uuid_t *u1, uuid_t *u2); - - uuid.c - - #include "copyrt.h" - #include - #include - #include - #include - #include "sysdep.h" - #include "uuid.h" - - /* various forward declarations */ - static int read_state(unsigned16 *clockseq, uuid_time_t *timestamp, - uuid_node_t * node); - static void write_state(unsigned16 clockseq, uuid_time_t timestamp, - uuid_node_t node); - static void format_uuid_v1(uuid_t * uuid, unsigned16 clockseq, - uuid_time_t timestamp, uuid_node_t node); - static void format_uuid_v3(uuid_t * uuid, unsigned char hash[16]); - static void get_current_time(uuid_time_t * timestamp); - static unsigned16 true_random(void); - - - Leach, Salz expires Aug 1998 [Page 18] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - /* uuid_create -- generator a UUID */ - int uuid_create(uuid_t * uuid) { - uuid_time_t timestamp, last_time; - unsigned16 clockseq; - uuid_node_t node; - uuid_node_t last_node; - int f; - - /* acquire system wide lock so we're alone */ - LOCK; - - /* get current time */ - get_current_time(×tamp); - - /* get node ID */ - get_ieee_node_identifier(&node); - - /* get saved state from NV storage */ - f = read_state(&clockseq, &last_time, &last_node); - - /* if no NV state, or if clock went backwards, or node ID changed - (e.g., net card swap) change clockseq */ - if (!f || memcmp(&node, &last_node, sizeof(uuid_node_t))) - clockseq = true_random(); - else if (timestamp < last_time) - clockseq++; - - /* stuff fields into the UUID */ - format_uuid_v1(uuid, clockseq, timestamp, node); - - /* save the state for next time */ - write_state(clockseq, timestamp, node); - - UNLOCK; - return(1); - }; - - /* format_uuid_v1 -- make a UUID from the timestamp, clockseq, - and node ID */ - void format_uuid_v1(uuid_t * uuid, unsigned16 clock_seq, uuid_time_t - timestamp, uuid_node_t node) { - /* Construct a version 1 uuid with the information we've gathered - * plus a few constants. */ - uuid->time_low = (unsigned long)(timestamp & 0xFFFFFFFF); - uuid->time_mid = (unsigned short)((timestamp >> 32) & 0xFFFF); - uuid->time_hi_and_version = (unsigned short)((timestamp >> 48) & - 0x0FFF); - uuid->time_hi_and_version |= (1 << 12); - uuid->clock_seq_low = clock_seq & 0xFF; - uuid->clock_seq_hi_and_reserved = (clock_seq & 0x3F00) >> 8; - uuid->clock_seq_hi_and_reserved |= 0x80; - memcpy(&uuid->node, &node, sizeof uuid->node); - }; - - - Leach, Salz expires Aug 1998 [Page 19] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - /* data type for UUID generator persistent state */ - typedef struct { - uuid_time_t ts; /* saved timestamp */ - uuid_node_t node; /* saved node ID */ - unsigned16 cs; /* saved clock sequence */ - } uuid_state; - - static uuid_state st; - - /* read_state -- read UUID generator state from non-volatile store */ - int read_state(unsigned16 *clockseq, uuid_time_t *timestamp, - uuid_node_t *node) { - FILE * fd; - static int inited = 0; - - /* only need to read state once per boot */ - if (!inited) { - fd = fopen("state", "rb"); - if (!fd) - return (0); - fread(&st, sizeof(uuid_state), 1, fd); - fclose(fd); - inited = 1; - }; - *clockseq = st.cs; - *timestamp = st.ts; - *node = st.node; - return(1); - }; - - /* write_state -- save UUID generator state back to non-volatile - storage */ - void write_state(unsigned16 clockseq, uuid_time_t timestamp, - uuid_node_t node) { - FILE * fd; - static int inited = 0; - static uuid_time_t next_save; - - if (!inited) { - next_save = timestamp; - inited = 1; - }; - /* always save state to volatile shared state */ - st.cs = clockseq; - st.ts = timestamp; - st.node = node; - if (timestamp >= next_save) { - fd = fopen("state", "wb"); - fwrite(&st, sizeof(uuid_state), 1, fd); - fclose(fd); - /* schedule next save for 10 seconds from now */ - next_save = timestamp + (10 * 10 * 1000 * 1000); - }; - }; - - Leach, Salz expires Aug 1998 [Page 20] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - - /* get-current_time -- get time as 60 bit 100ns ticks since whenever. - Compensate for the fact that real clock resolution is - less than 100ns. */ - void get_current_time(uuid_time_t * timestamp) { - uuid_time_t time_now; - static uuid_time_t time_last; - static unsigned16 uuids_this_tick; - static int inited = 0; - - if (!inited) { - get_system_time(&time_now); - uuids_this_tick = UUIDS_PER_TICK; - inited = 1; - }; - - while (1) { - get_system_time(&time_now); - - /* if clock reading changed since last UUID generated... */ - if (time_last != time_now) { - /* reset count of uuids gen'd with this clock reading */ - uuids_this_tick = 0; - break; - }; - if (uuids_this_tick < UUIDS_PER_TICK) { - uuids_this_tick++; - break; - }; - /* going too fast for our clock; spin */ - }; - /* add the count of uuids to low order bits of the clock reading */ - *timestamp = time_now + uuids_this_tick; - }; - - /* true_random -- generate a crypto-quality random number. - This sample doesn't do that. */ - static unsigned16 - true_random(void) - { - static int inited = 0; - uuid_time_t time_now; - - if (!inited) { - get_system_time(&time_now); - time_now = time_now/UUIDS_PER_TICK; - srand((unsigned int)(((time_now >> 32) ^ time_now)&0xffffffff)); - inited = 1; - }; - - return (rand()); - } - - - - Leach, Salz expires Aug 1998 [Page 21] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - /* uuid_create_from_name -- create a UUID using a "name" from a "name - space" */ - void uuid_create_from_name( - uuid_t * uuid, /* resulting UUID */ - uuid_t nsid, /* UUID to serve as context, so identical - names from different name spaces generate - different UUIDs */ - void * name, /* the name from which to generate a UUID */ - int namelen /* the length of the name */ - ) { - MD5_CTX c; - unsigned char hash[16]; - uuid_t net_nsid; /* context UUID in network byte order */ - - /* put name space ID in network byte order so it hashes the same - no matter what endian machine we're on */ - net_nsid = nsid; - htonl(net_nsid.time_low); - htons(net_nsid.time_mid); - htons(net_nsid.time_hi_and_version); - - MD5Init(&c); - MD5Update(&c, &net_nsid, sizeof(uuid_t)); - MD5Update(&c, name, namelen); - MD5Final(hash, &c); - - /* the hash is in network byte order at this point */ - format_uuid_v3(uuid, hash); - }; - - /* format_uuid_v3 -- make a UUID from a (pseudo)random 128 bit number - */ - void format_uuid_v3(uuid_t * uuid, unsigned char hash[16]) { - /* Construct a version 3 uuid with the (pseudo-)random number - * plus a few constants. */ - - memcpy(uuid, hash, sizeof(uuid_t)); - - /* convert UUID to local byte order */ - ntohl(uuid->time_low); - ntohs(uuid->time_mid); - ntohs(uuid->time_hi_and_version); - - /* put in the variant and version bits */ - uuid->time_hi_and_version &= 0x0FFF; - uuid->time_hi_and_version |= (3 << 12); - uuid->clock_seq_hi_and_reserved &= 0x3F; - uuid->clock_seq_hi_and_reserved |= 0x80; - }; - - /* uuid_compare -- Compare two UUID's "lexically" and return - -1 u1 is lexically before u2 - 0 u1 is equal to u2 - 1 u1 is lexically after u2 - - Leach, Salz expires Aug 1998 [Page 22] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - Note: lexical ordering is not temporal ordering! - */ - int uuid_compare(uuid_t *u1, uuid_t *u2) - { - int i; - - #define CHECK(f1, f2) if (f1 != f2) return f1 < f2 ? -1 : 1; - CHECK(u1->time_low, u2->time_low); - CHECK(u1->time_mid, u2->time_mid); - CHECK(u1->time_hi_and_version, u2->time_hi_and_version); - CHECK(u1->clock_seq_hi_and_reserved, u2->clock_seq_hi_and_reserved); - CHECK(u1->clock_seq_low, u2->clock_seq_low) - for (i = 0; i < 6; i++) { - if (u1->node[i] < u2->node[i]) - return -1; - if (u1->node[i] > u2->node[i]) - return 1; - } - return 0; - }; - - sysdep.h - - #include "copyrt.h" - /* remove the following define if you aren't running WIN32 */ - #define WININC 0 - - #ifdef WININC - #include - #else - #include - #include - #include - #endif - - /* change to point to where MD5 .h's live */ - /* get MD5 sample implementation from RFC 1321 */ - #include "global.h" - #include "md5.h" - - /* set the following to the number of 100ns ticks of the actual - resolution of - your system's clock */ - #define UUIDS_PER_TICK 1024 - - /* Set the following to a call to acquire a system wide global lock - */ - #define LOCK - #define UNLOCK - - typedef unsigned long unsigned32; - typedef unsigned short unsigned16; - typedef unsigned char unsigned8; - typedef unsigned char byte; - - Leach, Salz expires Aug 1998 [Page 23] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - - /* Set this to what your compiler uses for 64 bit data type */ - #ifdef WININC - #define unsigned64_t unsigned __int64 - #define I64(C) C - #else - #define unsigned64_t unsigned long long - #define I64(C) C##LL - #endif - - - typedef unsigned64_t uuid_time_t; - typedef struct { - char nodeID[6]; - } uuid_node_t; - - void get_ieee_node_identifier(uuid_node_t *node); - void get_system_time(uuid_time_t *uuid_time); - void get_random_info(char seed[16]); - - - sysdep.c - - #include "copyrt.h" - #include - #include "sysdep.h" - - /* system dependent call to get IEEE node ID. - This sample implementation generates a random node ID - */ - void get_ieee_node_identifier(uuid_node_t *node) { - char seed[16]; - FILE * fd; - static inited = 0; - static uuid_node_t saved_node; - - if (!inited) { - fd = fopen("nodeid", "rb"); - if (fd) { - fread(&saved_node, sizeof(uuid_node_t), 1, fd); - fclose(fd); - } - else { - get_random_info(seed); - seed[0] |= 0x80; - memcpy(&saved_node, seed, sizeof(uuid_node_t)); - fd = fopen("nodeid", "wb"); - if (fd) { - fwrite(&saved_node, sizeof(uuid_node_t), 1, fd); - fclose(fd); - }; - }; - inited = 1; - }; - - Leach, Salz expires Aug 1998 [Page 24] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - *node = saved_node; - }; - - /* system dependent call to get the current system time. - Returned as 100ns ticks since Oct 15, 1582, but resolution may be - less than 100ns. - */ - #ifdef _WINDOWS_ - - void get_system_time(uuid_time_t *uuid_time) { - ULARGE_INTEGER time; - - GetSystemTimeAsFileTime((FILETIME *)&time); - - /* NT keeps time in FILETIME format which is 100ns ticks since - Jan 1, 1601. UUIDs use time in 100ns ticks since Oct 15, 1582. - The difference is 17 Days in Oct + 30 (Nov) + 31 (Dec) - + 18 years and 5 leap days. - */ - - time.QuadPart += - (unsigned __int64) (1000*1000*10) // seconds - * (unsigned __int64) (60 * 60 * 24) // days - * (unsigned __int64) (17+30+31+365*18+5); // # of days - - *uuid_time = time.QuadPart; - - }; - - void get_random_info(char seed[16]) { - MD5_CTX c; - typedef struct { - MEMORYSTATUS m; - SYSTEM_INFO s; - FILETIME t; - LARGE_INTEGER pc; - DWORD tc; - DWORD l; - char hostname[MAX_COMPUTERNAME_LENGTH + 1]; - } randomness; - randomness r; - - MD5Init(&c); - /* memory usage stats */ - GlobalMemoryStatus(&r.m); - /* random system stats */ - GetSystemInfo(&r.s); - /* 100ns resolution (nominally) time of day */ - GetSystemTimeAsFileTime(&r.t); - /* high resolution performance counter */ - QueryPerformanceCounter(&r.pc); - /* milliseconds since last boot */ - r.tc = GetTickCount(); - r.l = MAX_COMPUTERNAME_LENGTH + 1; - - Leach, Salz expires Aug 1998 [Page 25] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - GetComputerName(r.hostname, &r.l ); - MD5Update(&c, &r, sizeof(randomness)); - MD5Final(seed, &c); - }; - #else - - void get_system_time(uuid_time_t *uuid_time) - { - struct timeval tp; - - gettimeofday(&tp, (struct timezone *)0); - - /* Offset between UUID formatted times and Unix formatted times. - UUID UTC base time is October 15, 1582. - Unix base time is January 1, 1970. - */ - *uuid_time = (tp.tv_sec * 10000000) + (tp.tv_usec * 10) + - I64(0x01B21DD213814000); - }; - - void get_random_info(char seed[16]) { - MD5_CTX c; - typedef struct { - struct sysinfo s; - struct timeval t; - char hostname[257]; - } randomness; - randomness r; - - MD5Init(&c); - sysinfo(&r.s); - gettimeofday(&r.t, (struct timezone *)0); - gethostname(r.hostname, 256); - MD5Update(&c, &r, sizeof(randomness)); - MD5Final(seed, &c); - }; - - #endif - - utest.c - - #include "copyrt.h" - #include "sysdep.h" - #include - #include "uuid.h" - - uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */ - 0x6ba7b810, - 0x9dad, - 0x11d1, - 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 - }; - - - - Leach, Salz expires Aug 1998 [Page 26] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - /* puid -- print a UUID */ - void puid(uuid_t u); - - /* Simple driver for UUID generator */ - void main(int argc, char **argv) { - uuid_t u; - int f; - - uuid_create(&u); - printf("uuid_create() -> "); puid(u); - - f = uuid_compare(&u, &u); - printf("uuid_compare(u,u): %d\n", f); /* should be 0 */ - f = uuid_compare(&u, &NameSpace_DNS); - printf("uuid_compare(u, NameSpace_DNS): %d\n", f); /* s.b. 1 */ - f = uuid_compare(&NameSpace_DNS, &u); - printf("uuid_compare(NameSpace_DNS, u): %d\n", f); /* s.b. -1 */ - - uuid_create_from_name(&u, NameSpace_DNS, "www.widgets.com", 15); - printf("uuid_create_from_name() -> "); puid(u); - }; - - void puid(uuid_t u) { - int i; - - printf("%8.8x-%4.4x-%4.4x-%2.2x%2.2x-", u.time_low, u.time_mid, - u.time_hi_and_version, u.clock_seq_hi_and_reserved, - u.clock_seq_low); - for (i = 0; i < 6; i++) - printf("%2.2x", u.node[i]); - printf("\n"); - }; - -Appendix B _ Sample output of utest - - uuid_create() -> 7d444840-9dc0-11d1-b245-5ffdce74fad2 - uuid_compare(u,u): 0 - uuid_compare(u, NameSpace_DNS): 1 - uuid_compare(NameSpace_DNS, u): -1 - uuid_create_from_name() -> e902893a-9d22-3c7e-a7b8-d6e313b71d9f - -Appendix C _ Some name space IDs - - This appendix lists the name space IDs for some potentially - interesting name spaces, as initialized C structures and in the - string representation defined in section 3.5 - - uuid_t NameSpace_DNS = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */ - 0x6ba7b810, - 0x9dad, - 0x11d1, - 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 - }; - - - Leach, Salz expires Aug 1998 [Page 27] - - - Internet-Draft UUIDs and GUIDs (DRAFT) 02/04/98 - - - uuid_t NameSpace_URL = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */ - 0x6ba7b811, - 0x9dad, - 0x11d1, - 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 - }; - - uuid_t NameSpace_OID = { /* 6ba7b812-9dad-11d1-80b4-00c04fd430c8 */ - 0x6ba7b812, - 0x9dad, - 0x11d1, - 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 - }; - - uuid_t NameSpace_X500 = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ - 0x6ba7b814, - 0x9dad, - 0x11d1, - 0x80, 0xb4, 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 - }; - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -