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
<draft-lloyd-ldap-distribution-00.txt>
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
<draft-lloyd-ldap-svcs-00.txt> and <draft-lloyd-list-read-00.txt>.
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
<draft-lloyd-ldap-svcs-00.txt> 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