LDAPEXT Working Group Alan Lloyd INTERNET-DRAFT PROPOSAL OpenDirectory Intended Category: Standards Track Expires: TBD 25 September 1998 Distribution: LDAP server transition to X.500 1. Status of this Memo This draft document will be submitted to the RFC Editor as an informational document. Distribution of this memo is unlimited. Please send comments to the author(s). 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.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2. Abstract This document defines chaining arguments that can be applied to any LDAP operation for distributed/chained server to server operations. This approach to distribution for LDAP systems, enables a consistent transition of the LDAP single server environments, to the full functionality of X.500 distributed directory systems. This proposal is supported by two other proposals previously submitted as and . These proposals require that LDAP V3 is evolved to LDAP V4. LDAP V4 will enable LDAP clients and servers that access and interwork with X.500 systems, to more readily use (and integrate with) the full distribution and replication services offered by X.500. In addition this approach will provide better compatability with the higher functionality afforded to X.500 DAP clients. (Although the commonly known information restrictions of LDAP string encoding may still apply). The Chaining controls proposed in this draft will be carried with the original LDAP access client controls as defined in in the standard LDAP V4 operations (Search, List, etc) when it is used for server - server communication. ie. chaining. Rationale: In large organisations, the rapid transition to X.500 is essential because of the restrictions in functionality and higher operational costs associated with non distributed LDAP server directory systems. These costs are due to the requirement to replicate all LDAP server information to all other LDAP servers (for User authentication), and hand configure masses of system knowledge and data and new servers are connected. Obviously this cost situation worsens as the LDAP system scales. Experience in the market place is showing that major corporates require fully distributed directory systems (with some replication facilities) thatsupport chaining and mutual authentication techniques between servers, as well a consistent naming, access control, loop detection and DIT management (features as provided by standard X.500). These features are also fundamental to X.509 certificate path processing in a wider EC environment. It follows that LDAP severs need to evolve to the cpabilities as provided by X.500 systems and that as they do, common protocols and directory information techniques should be applied. This proposal adds to LDAP V4 controls, the chaining arguments of [X.518], distribution. Chaining protocols (DSP in X.500) also permit the extraction of master or replica data from within the X.500 directory system and provide this to the client (via LDAP) without the need for complex client software and client based LDAP referrals to different servers. Note: Some X.500 products with LDAP client access also support the connection of LDAP servers as subordinate directory systems (convert DSP into LDAP). ie. Where there is an urgent requirement for distribution in LDAP only environments, this X.500 capability can be used. Cautionary note: Distributed directory systems require a lot more than a simple protocol to be defined. ie. a fully functioning distributed DIT, knowledge, administration and access control regimes must be implemented as well as mutual authentication techniques and Search/List results correlation. In addition the issues of Root Level and First level DSAs must be addressed as well as the inteconnectivity and compatability of other supplier's server products. It is therefore recommended that those considering upgrading LDAP server technology to that as provided by X.500 are aware of the development costs, resources and time. ie there is no such thing as a simple protocol to resolve the complex issues associated with robust, distributed, object oriented directory information systems. 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 to implement the features required is to use the LDAP (V4) Controls mechanism and define this in an identical manner (as appropriate)as [X.518]. This field in LDAP has been provided for the very purpose. ie. to enable a LDAP client and servers to control directory system services in the manner described. In the proposal, the control element defined only applies to server - server protocol exchanges. Any client receiving the Chaining Control element in the LDAP exchange MUST process it as an error. 4. Chaining Controls This control may be included in the Controls portion of any LDAPv4 message. The controlType is "2.16.840.1.TBD". LDAP V3 defines the control field as: Control ::= SEQUENCE { controlType LDAPOID, criticality BOOLEAN DEFAULT FALSE, controlValue OCTET STRING OPTIONAL } Where criticality is operationally required to be different for different chaining controls, a sequence of LDAP control elements can be provided with the critical service controls set in one LDAP Control element and non critical chaining controls set in another. The Control Value field is encoded as follows: ChainingArguments ::= SET { originator [0] DistinguishedName OPTIONAL, targetObject [1] DistinguishedName OPTIONAL, operationProgress [2] OperationProgress DEFAULT { nameResolutionPhase notStarted }, traceInformation [3] TraceInformation, aliasDereferenced [4] BOOLEAN DEFAULT FALSE, aliasedRDNs [5] INTEGER OPTIONAL, -- absent unless aliasDereferenced is TRUE returnCrossRefs [6] BOOLEAN DEFAULT FALSE, referenceType [7] ReferenceType DEFAULT superior, info [8] DomainInfo OPTIONAL, timeLimit [9] Time OPTIONAL, -- choice UTC/generalised. securityParameters [10] SecurityParameters DEFAULT { }, entryOnly [11] BOOLEAN DEFAULT FALSE, uniqueIdentifier [12] UniqueIdentifier OPTIONAL, authenticationLevel [13] AuthenticationLevel OPTIONAL, exclusions [14] Exclusions OPTIONAL, excludeShadows [15] BOOLEAN DEFAULT FALSE, nameResolveOnMaster [16] BOOLEAN DEFAULT FALSE, operationIdentifier [17] INTEGER OPTIONAL } The various components have the meanings as defined below: a) The originator component conveys the name of the (ultimate) originator of the request unless already specified in the security parameters. If requester is present in other LDAP parameters, this argument may be omitted. b) The targetObject component conveys the name of the object whose directory entry is being routed to. The role of this object depends on the particular operation concerned: it may be the object whose entry is to be operated on, or which is to be the base object for a request or sub request involving multiple objects (e.g. ChainedList or ChainedSearch). This component can be omitted only if it has the same value as the object or base object parameter in the chained operation, in which case its implied value is that value. Where the targetObject includes RDNs containing attribute type and value pairs for which there are multiple distinguished values differentiated by context, the RDNs that have been resolved shall be primary RDNs. c) The operationProgress component is used to inform the DSA of the progress of the operation, and hence of the role which it is expected to play in its overall performance. The information conveyed in this component is specified in [X.518]. d) The traceInformation component is used to prevent looping among DSAs/ LDAP servers when chaining is in operation. A DSA adds a new element to trace information prior to chaining an operation to another DSA. On being requested to perform an operation, a DSA checks, by examination of the trace information, that the operation has not formed a loop. The information conveyed in this component is specified in [X.518]. e) The aliasDereferenced component is a BOOLEAN value which is used to indicate whether or not one or more alias entries have so far been encountered and dereferenced during the course of distributed name resolution. The default value of FALSE indicates that no alias entry has been dereferenced. f) The aliasedRDNs component indicates how many of the RDNs in the targetObject Name have been generated from the aliasedEntryName attributes of one (or more) alias entries. The integer value is set whenever an alias entry is encountered and dereferenced. This component shall be present if and only if the aliasDereferenced component is TRUE. g) The entryOnly component is set to TRUE if the original operation was a search, with the subset argument set to oneLevel and an alias entry was encountered as an immediate subordinate of the baseObject. The DSA which successfully performs name resolution on the targetObject name, shall perform object evaluation on only the named entry. h) The returnCrossRefs component is a Boolean value which indicates whether or not knowledge references, used during the course of performing a distributed operation, are requested to be passed back to the initial DSA as cross references, along with a result or referral. The default value of FALSE indicates that such knowledge references are not to be returned. i) The referenceType component indicates, to the DSA being asked to perform the operation, what type of knowledge was used to route the request to it. The DSA may therefore be able to detect errors in the knowledge held by the invoker. If such an error is detected it shall be indicated by a ServiceError with the invalidReference problem. ReferenceType is described fully in [X.518]. j) The info component is used to convey DMD-specific information among DSAs which are involved in the processing of a common request. This component is of type DomainInfo, which is of unrestricted type: DomainInfo ::= ABSTRACT-SYNTAX.&Type k) The timeLimit component, if present, indicates the time by which the operation is to be completed. l) The SecurityParameters component is specified in [X.511]. Its absence is deemed equivalent to there being an empty set of security parameters. m) AuthenticationLevel is optionally supplied when it is required to indicate the manner in which authentication has been carried out. The AuthenticationLevel element is described in [X.501]. n) UniqueIdentifier is optionally supplied when it is required to confirm the originator name. The UniqueIdentifier element is described in [X.501]. o) The entryOnly component is set to TRUE if the original operation was a Search with the subset argument set to oneLevel, and an alias entry was encountered as an immediate subordinate of the baseObject. The DSA which successfully performs name resolution on the targetObject name shall perform object evaluation on only the named entry. p) The exclusions component has significance only for Search operations; it indicates, if present, which subtrees of entries subordinate to the targetObject shall be excluded from the result of the Search operation. q) The excludeShadows component has significance only for Search and List operations; it indicates that the search shall be applied to entries and not to entry copies. This optional component may be used by a DSA as one way to avoid the receipt of duplicate results. r) The nameResolveOnMaster component only has significance during name resolution, and is only set if NSSRs have been encountered. If set to TRUE, it signals that subsequent name resolution, i.e. matching the remaining RDNs from nextRDNToBeResolved, shall not employ entry copy information; subsequent resolution of each remaining RDN shall be done in the master DSA for the entry identified by that RDN. (s) The operationIdentifier component facilitates the correlation of DAP operations with subsequent related DSP operations as well as with results. It is assigned by the DSA that first receives a DAP request or is copied from the chaining arguments of DSP requests that require further chaining. The DSA assigning the operationIdentifier shall not reuse the assigned integer for a sufficiently long time period. Correlation of related DAP and DSP requests and results is facilitated by a DSA logging for each operation and result the operationIdentifier together with the name of the DSA that assigned it (the first DSA in traceInformation on a chained request). Such correlation may be useful for the purposes of logging, auditing, charging and settlements, etc. 5.0 Chaining Results The ChainingResults are present in the result of each operation and provide feedback to the DSA which invoked the operation. ChainingResults ::= SET { info [0] DomainInfo OPTIONAL, crossReferences [1] SEQUENCE OF CrossReference OPTIONAL, securityParameters [2] SecurityParameters DEFAULT { }, alreadySearched [3] Exclusions OPTIONAL } The various components have the meanings as defined below: a) The info component is used to convey DMD-specific information among DSAs which are involved in the processing of a common request. This component is of type DomainInfo, which is of unrestricted type. b)The crossReferences component is not present in the ChainingResults unless the returnCrossRefs component of the corresponding request had the value TRUE. This component consists of a sequence of CrossReference items, each of which contains a contextPrefix and an accessPoint descriptor. For fuller definitions and parameter syntaxes of the above see [X.518]. 6. Compliance Upon receiving the controls as defined, a server that supports them MUST process this as a distributed LDAP V4 operation. Compliance to the support of the above controls will be specified in the respective Server or Client profiles or X.500/DAP/DSP/LDAP ISPs. 7. Security Considerations The security of distributed directories is dealt with via a distributed trust model and mutual authentication techniques (see X.501/509). Therefore,servers (DSAs) that implement the mechanism described in this document SHOULD provide a means to enforce distributed user authentication and access controls on the distributed entries and prevent the mis use of these controls via pre configured default values. 8. Associated Proposals This proposal accompanies two proposals to align the aspects of LDAP V3 and X.511. draft-lloyd-ldap-list-read-00.txt draft-lloyd-ldap-svcs-00.txt 9. Acknowledgements This document is an update to RFC 2251, by Mark. Wahl, ,Tim Howes, and Steve Kille. Design ideas included in this document are based on those provided in the X.500 ISO/ITU specifications. The contributions of individuals in these working groups is gratefully acknowledged. 10. The views expressed are those of the author. 11. Copyright TBS 12. 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. [X.208] CCITT Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1), 1988. [X.501] ITU-T Recommendation X.501: Information Technology - Open Systems Interconnection - The Directory: Models, 1993. [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997. [X.511] ITU-T Recommendation X.511: Information Technology - Open Systems Interconnection - The Directory: Abstract Service Definition(DAP), 1993/7. [X.518] ITU-T Recommendation X.511: Information Technology - Open Systems Interconnection - The Directory: Procedures for Distributed Operations(DSP),1993 [X.520] ITU-T Recommendation X.520: Information Technology - Open Systems Interconnection - The Directory: Selected Attribute Types, 1993. [X.521] ITU-T Recommendation X.520: Information Technology - Open Systems Interconnection - The Directory: Selected Object Classes, 1993. [X.525] ITU-T Recommendation X.511: Information Technology - Open Systems Interconnection - The Directory: Replication (DISP), 1993. 13. Author's Addresses Alan Lloyd OpenDirectory Pty Ltd. 266 Maroondah Highway Mooroolbark Melbourne Vic 3138 Australia +61 3 9727 8900 mobile + 61 418 536 749 alan.lloyd@opendirectory.com.au