Re: I-D ACTION:draft-ietf-ldup-framing-profile-00.txt
Ryan Moats <[email protected]>
| Newsgroups | gmane.ietf.ldup |
|---|---|
| Message-ID | <[email protected]> |
I-D editor:
please insert the following (below '...===cuthere')
as draft-ietf-ldup-mrm-00.txt.
LDUP:
Here's -00 of Mandatory LDAP Replica Management. Many thanks to Mark
and Ed for the initial text. A lot of this document is still TBD
(as you will see), but we wanted to get something in the repository
for SLC and we've fleshed out enough of it for us to ask the WG
for consensus on the following issues.
1. In Section 4.5, do we need the ability to copy (i.e. read and set) all
operational attributes as part of this operation? If so, LDAP will need
a change.
2. Section 4.6 currently requires that all replicaSubentries representing the
same server have the same entryUUID. How is this accomplished?
3. Section 5.1.1 posits some out-of-band transport for the initial copy
of the source server. Is LDIF appropriate for this transport? If so,
how do we carry replication meta-data (e.g. CSNs)?
4. Should the operations in section 5.12 be condensed into a single extended
operation? The rationale behind an extended operation is that this should
be a mechanical process. Having a mechanism to "replicate" this from one
server to the others:
- reduces likelihood of missing something
- allows replication framework to ensure that this information gets to
every server in the event that a server is down or so
Enjoy
Ryan Moats (for the authors)
=============================cut here
Internet-Draft Ryan Moats
LDAP Duplication/Replication/Update Lemur Networks, Inc.
Protocols WG Rick Huber
Intended Category: Standard AT&T Laboratories
Expires May 2002 John McMeeking
IBM
November 2001
Mandatory LDAP Replica Management
Filename: draft-ietf-ldup-mrm-00.txt
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/lid-abstracts.txt.
The list of Internet-Drafts Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The goal of standards for LDAP replication is to allow interoperable
replication among products from many different vendors. Defining the
mechanism to move data among replicas is a necessary part of this work,
but management of the replicated environment must also be standardized
for replication to be truly interoperable.
This document presents the replication management functions that must
be performed. Whenever possible, these functions are defined in terms
of existing LDAP functionality using existing LDAP operations and
existing data definitions. In some cases, changes or additions to the
existing model are requires, and specifications for these changes are
included in this document.
Moats, et al Expires May 2002 [Page 1]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
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].
1 Table of Contents
Status of this Memo...................................................1
Abstract..............................................................1
1 Table of Contents ..................................................2
2 Introduction .......................................................3
3 Administrative Precursors ..........................................4
4 Operational "Atoms" ................................................4
4.1 Create replicaContext on a single server .......................5
4.2 Delete replicaContext from a single server .....................5
4.3 Add area of replication to a server ............................5
4.4 Delete area of replication from a server .......................6
4.5 Copy base of area of replication between servers ...............6
4.6 Create server entry in area of replication .....................6
4.7 Delete Server Entry for an area of replication .................7
4.8 Modify replica .................................................7
4.8.1 Change Replica Type .........................................7
4.8.2 Change Between Full/Partial Replica .........................7
4.8.3 Change Replica URI for one server for one area of replication
7
4.9 Add Replication Agreement ......................................7
4.10 Delete Replication Agreement .................................8
4.11 Modify Replication Agreement .................................8
4.12 Suspend Replication ..........................................8
4.13 Resume Replication ...........................................8
4.14 Trigger an Immediate Replica Cycle ...........................8
5 Common Tasks .......................................................8
5.1 Add a new replica to an existing replica group .................9
5.1.1 Large area of replication support ...........................9
5.2 Set up (but do not start) replication between two servers ......9
5.3 Set up (but do not start) replication between a server and an
existing replica group ..............................................9
5.4 Verify replication information is present between two servers ..9
5.5 Start replication between two servers. .........................9
5.6 Start replication between an existing replica group and a new
server ..............................................................9
5.7 Temporarily Suspend all replication activity from a given server
9
5.8 Halt replication on all areas of a server ......................9
5.9 List status of a particular area of replication on a given
server ..............................................................9
5.10 List all areas of replication defined on a given server and
their status .......................................................10
5.11 Restore a server and replication agreements after a server
crash 10
5.12 Split an Area of Replication ................................10
5.13 Move an existing area of replication to a new server ........10
5.14 Join two Areas of Replication ...............................10
5.14.1 Preconditions ............................................10
Moats, et al Expires May 2002 [Page 2]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
5.14.2 Procedure ................................................10
5.14.3 Server requirements ......................................11
5.15 Stop Replicating an Area of Replication. ....................11
5.16 Suspending and Resuming Replication .........................12
5.17 Convert a read-only replica to an updateable replica ........12
5.18 Changing Replica URI on all servers handling an area of
replication ........................................................12
5.19 Postpone a Replica Cycle to a Later Time ....................12
5.20 Examine Replication Audit History on a Server ...............12
5.21 Compare Two Replicas on Two Servers for Differences .........12
5.22 Fix an Entry Without Triggering Replication .................12
5.23 Check Reported Schema Mismatches Discovered During Replication
13
5.24 Adding a new directory server to a replica group and
initializing the contents ..........................................13
5.25 Restore from the master failure in a single-master system ...13
6 Formal Specifications .............................................13
6.1 New/Modified Object Classes ...................................13
6.2 New/Modified Attributes .......................................13
6.3 New/Modified Extended Operations ..............................13
6.4 New/Modified Replication Primitives ...........................14
7 Security Considerations ...........................................14
8 Acknowledgements ..................................................14
9 References ........................................................14
Author's Addresses:..................................................15
Full Copyright Statement.............................................15
2 Introduction
In the LDAP replication architecture [Arch], the LDAP servers and
replication agreements between them are represented by entries in the
directory tree, as part of the replicated naming context. The LDAP
replication information model [InfoMod] describes the contents of these
entries.
Replication management entries, such as replicaSubentries or
replication agreements, can be altered on any updateable replica. These
entries are implicitly included in the directory entries governed by
any agreement associated with this area of replication. As a result,
all servers with a replica of an area of replication will have access
to information about all other replicas of that area of replication and
associated agreements.
The deployment and maintenance of a replicated directory network
involves the creation and management on the replicas themselves and
associated replication control information (e.g. replicationSubentries
and replication agreements). This document outlines the administrative
actions necessary to create and maintain replication agreements.
Typically, administrative tools will guide the administrator and
facilitate these actions.
Moats, et al Expires May 2002 [Page 3]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
3 Administrative Precursors
In this document the term "administrative user" refers to an identity
that will be performing replication configuration by binding to and
invoking operations on directory servers. Most LDAP server
implementations have the concept of a superuser or power user, however
this need not be the same as the administrative user, so long as the
administrative user has been granted appropriate privileges. The
administrative user MAY be running as an autonomous process, and MUST
be capable of securely maintaining its own credentials.
Servers SHOULD support the concept of there being multiple
administrative users, and SHOULD allow each to have distinct rights
from the others.
Deployments SHOULD create an administrative user identity that is
granted access to all servers holding a replica of a naming context to
perform the procedures described below, in particular to read the root
DSE, the replicationContext prefix entry and all subordinate
subentries. The administrative user who will be viewing or modifying
the replication status MUST have already been provided with and
established in the directory server or servers appropriate
authentication credentials and authorization rights to retrieve
attributes and invoke DIT modification operations that are beyond the
ability of the 'average' directory user.
Through out-of-band means one of the following will have occurred:
1.
the administrative user and the directory server have agreed upon
a shared secret which the administrator will use to authenticate
itself, or
2.
the administrative user will have a certificate that can be
validated by the directory server.
Note that the secret in the first case need not be held by the
directory server itself but could be maintained by an authentication
service trusted by the directory server.
4 Operational "Atoms"
The following operational atoms are used to build up more complex tasks
in section 5.
Most of these operational "atoms" make the following assumptions:
Through prior LDAP or out-of-band means the administrative user MUST
have been granted the following access control permissions to the
directory in order to establish replication:
-Modify the attribute 'replicaContextRoots' of the root DSE by
adding values
-Create the naming context prefix entry
Moats, et al Expires May 2002 [Page 4]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
-Create subentries immediately below the naming context prefix
entry
In several sections below, we refer to "source" and "target" servers.
The "source" server is a server that already holds a copy of the area
of replication. It may already be replicating that area with other
servers. The "target" server does not currently hold a copy of the
area of replication. The "target" is being added to the replica-group.
Issue: Any write or modify being done to a readOnly replica requires
some thought.
Issue: Whether each of these atoms is propagated by replication and how
it impacts the replication process.
4.1 Create replicaContext on a single server
The client SHOULD invoke a ModifyRequest in which the object field is
the empty string (naming the root DSE), and the modification list
consists of a single item to add the distinguished name of the context
prefix to the attribute replicaContextRoots. If the server responds
with the resultCode attributeOrValueExists, then the value is already
there. If the server responds with a resultCode other than
attributeOrValueExists or success, then this is an error.
4.2 Delete replicaContext from a single server
The client SHOULD invoke a ModifyRequest in which the object field is
the empty string (naming the root DSE), and the modifications list
consists of a single item, to delete the value of the distinguished
name of the context prefix from the attribute replicaContextRoots. If
the server responds with the resultCode noSuchAttribute, then the value
has already been removed. If the server responds with a resultCode
other than noSuchAttribute or success, then this is an error.
4.3 Add area of replication to a server
The client SHOULD invoke a ModifyRequest in which the object field is
the context prefix of the replication context, and the modification
list consists of a single item to add the value replicationContext to
the attribute objectClass. If the server responds with the resultCode
attributeOrValueExists, then the value is already there. If the server
responds with a resultCode other than attributeOrValueExists or
success, then this is an error. Should an error occur at this point,
the server is in an inconsistent state and needs to be fixed.
After this step is completed, the server will begin storing change
information for this area of replication.
WG ISSUE: If replicaContextRoots were an operational attribute, then it
would be possible to have the server maintain that attribute when
replicationContext is added or deleted. Without it, these steps need
Moats, et al Expires May 2002 [Page 5]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
to be separate LDAP protocol operations and thus it is possible to have
inconsistent states.
4.4 Delete area of replication from a server
The client SHOULD invoke a ModifyRequest in which the object field is
the context prefix of the replication context, and the modification
list consists of a single item to remove the value replicationContext
to the attribute objectClass. If the server responds with the
resultCode noSuchAttribute, then the value has already been removed.
If the server responds with a resultCode other than noSuchAttribute or
success, then this is an error.
After this step is completed, the server will no longer replicate this
area of replication.
4.5 Copy base of area of replication between servers
In this section, the 'target server' is the server on which the client
has just modified the root DSE.
The client MUST separately contact another server, one that already
holds a copy of this replication context, and issue a SearchRequest on
that server in which the baseObject is the DN of the of base the area
of replication, the scope baseObject, the filter "(objectClass=*)" and
the attributes list "*". If the client cannot obtain the single entry
at this point, the procedure will fail, and the client SHOULD invoke on
the slave server a ModifyRequest in which the object field is the empty
string, and the modifications list consists of a single item, a delete
of the attribute replicaContextRoots with the value the distinguished
name of the context prefix.
WG Issue: Do we need the ability to copy (i.e. read and set) all
operational attributes as part of this operation? If so, LDAP will need
a change.
Now that it has the entry, the client SHOULD invoke an AddRequest on
the target server with entry set to the DN of the base of the area of
replication and attributes the same list as obtained in the previous
search.
If the server returns a resultCode other than success, it is an error,
and the server will be in an inconsistent state.
4.6 Create server entry in area of replication
Each server needs to have in its copy of the area of replication a
replicaSubentry for each of the servers involved in replicating that
area before replication can be started. These entries MUST have the
following attributes:
1. objectclass, with values top, ldapSubentry and replicaSubentry
2. cn
3. replicaURI
Moats, et al Expires May 2002 [Page 6]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
4. replicaType
5. replicaOnline
and MAY contain other attributes, as described in the Information Model
[InfoMod].
WG Issue: This requires that all replicaSubentries representing the
same server have the same entryUUID. How is this accomplished?
4.7 Delete Server Entry for an area of replication
The client SHOULD issue a SearchRequest in which the baseObject is the
DN of the context prefix, the scope oneLevel, the filter
"(objectClass=replicaSubentries)" and the attributes list. For each
entry returned, the client SHOULD then issue a DeleteReques in which
the object field is the DN of the entry. If the server responds with
the resultCode noSuchObject, then the entry has already been removed.
If the server responds with a resultCode other than noSuchObject or
success, then this is an error.
4.8 Modify replica
4.8.1 Change Replica Type
Note: This section covers only the simple protocol operation to change
the replica type. Section 5.17 coverts the full set of operations for
converting from a ReadOnly to an Updateable replica.
The client SHOULD invoke a ModifyRequest in which the object field is
the replicationSubentry, and the modification list consists of a single
item to change the value of the attribute replicaType. If the server
responds with the resultCode attributeOrValueExists, then the value is
already there. If the server responds with a resultCode other than
attributeOrValueExists or success, then this is an error.
4.8.2 Change Between Full/Partial Replica
TBD
4.8.3 Change Replica URI for one server for one area of replication
Note: This section covers only the simple protocol operation to change
the replica type. Section 5.18 covers the full set of operations for
changing the replica URI on all servers.
The client SHOULD invoke a ModifyRequest in which the object field is
the replicationSubentry, and the modification list consists of a single
item to change the value of the attribute replicaURI to the new value.
If the server responds with the resultCode attributeOrValueExists, then
the value is already there. If the server responds with a resultCode
other than attributeOrValueExists or success, then this is an error.
4.9 Add Replication Agreement
TBD
Moats, et al Expires May 2002 [Page 7]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
4.10 Delete Replication Agreement
The termination of replication agreements should be done with caution
as it can easily result in a partition of the directory servers if
performed incorrectly.
Once all replication agreements have been terminated between a server
and others for a naming context, then that copy of the context on the
server will be divergent, and any updates made there will not be
propagated to any other server.
TBD
4.11 Modify Replication Agreement
TBD
4.12 Suspend Replication
The client SHOULD invoke a ModifyRequest in which the object field is
the DN of the target replicationSubentry, and the modification list
consists of a single item to change the value of replicaOnline
attribute to false. If the server responds with the resultCode
attributeOrValueExists, then the value is already there. If the server
responds with a resultCode other than attributeOrValueExists or
success, then this is an error.
4.13 Resume Replication
The client SHOULD invoke a ModifyRequest in which the object field is
the DN of the target replicationSubentry, and the modification list
consists of a single item to change the value of replicaOnline
attribute to true. If the server responds with the resultCode
attributeOrValueExists, then the value is already there. If the server
responds with a resultCode other than attributeOrValueExists or
success, then this is an error.
4.14 Trigger an Immediate Replica Cycle
TBD
Issue: An administrative client could trigger an immediate replication
cycle by issuing a "Trigger Replication" extended operation to the
supplier server. The extended operation value specifies the DN of a
replication agreement between the supplier and target replicas, and the
type of replication session to be performed (full update or incremental
update). The replication agreement is used to specify the target
replica, connection information, and authentication information.
5 Common Tasks
There are many tasks that administrators need to perform in a
replicated environment. This section describes many typical tasks and
describes how they are performed in terms of the atoms defined above.
Moats, et al Expires May 2002 [Page 8]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
5.1 Add a new replica to an existing replica group
TBD
5.1.1 Large area of replication support
In some cases, an area of replication is so large or available
bandwidth so small that out-of-band mechanisms (e.g. mailing a tape)
need to be used to transport the initial copy from the source to the
target. The target then needs to be updated with changes made to the
source since the copy was made. This section describes how this
situation is handled.
Details TBD.
WG Issue: is LDIF appropriate for this transport? If so, how do we
carry replication meta-data (e.g. CSNs)?
5.2 Set up (but do not start) replication between two servers
TBD
5.3 Set up (but do not start) replication between a server and an
existing replica group
TBD
5.4 Verify replication information is present between two servers
TBD
5.5 Start replication between two servers.
For this operation, the client SHOULD follow the steps in Section 5.2
followed by starting replication as specified in Section 4.13.
5.6 Start replication between an existing replica group and a new
server
For this operation, the client SHOULD follow the steps in Section 5.3
followed by starting replication as specified in Section 4.13.
5.7 Temporarily Suspend all replication activity from a given server
TBD
5.8 Halt replication on all areas of a server
TBD
5.9 List status of a particular area of replication on a given server
TBD
Moats, et al Expires May 2002 [Page 9]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
5.10 List all areas of replication defined on a given server and their
status
TBD
5.11 Restore a server and replication agreements after a server crash
TBD
5.12 Split an Area of Replication
To split an area of replication, the atoms are:
1. Add the subordinate area of replication to the servers'
replicaContextRoots (Section 4.1)
2. Add the replicationContext objectclass to the root entry of the
area of replication (Section 4.3)
3. Create replicaSubentry objects under the new area of replication
for each replica of the parent area of replication (Section 4.6)
4. Create replicaAgreement objects (and schedules?) under the new
replicaSubentries, where agreements are created that correspond to
each agreement defined for the parent (Section 4.9).
These operations must be performed on each server containing a replica
of the parent area of replication.
WG Issue: Extended op or not? The rationale behind an extended
operation is that this should be a mechanical process. Having a
mechanism to "replicate" this from one server to the others:
- reduces likelihood of missing something
- allows replication framework to ensure that this information gets to
every server in the event that a server is down or some other error
prevents the client from completing all of these operations.
5.13 Move an existing area of replication to a new server
TBD
5.14 Join two Areas of Replication
This section describes how to join two areas of replication.
5.14.1 Preconditions
Before joining two areas of replication there are certain preconditions
that need to be satisfied:
1. Any server that contains a replica of one area of replication must
also contain a replica of the other area of replication. This may
require copying either area of replication to additional servers,
or deleting either area of replication from servers.
2. The replicas on any given server MUST be of the same type. Both
replicas must be updateable, both-readonly, or both primary.
Furthermore, if the replicas are readonly, they must both be full
replicas, or must both be fractional replicas with identical
fractional entry specifications.
5.14.2 Procedure
Moats, et al Expires May 2002 [Page 10]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
1. On each server, delete the replicationContext objectclass value from
the subordinate area of replication (Section TBD).
We'd like this to be replicated under the parent area of replication,
and we'd like this to have the affect of causing all not yet
replicated updates and future client changes as if they occurred
under the parent area f replication. This is going to cause problems
with respect to CSNs if there are "old" changes in the subordinate
context. Maybe we require that there be no pending updates? This is
going to be potentially ugly.
2.
Delete all replication agreements for the subordinate area of
replication
3.
Delete all replicaSubentries for the subordinate area of replication
5.14.3 Server requirements
When the replicationContext objectclass is removed from the root of an
area of replication, the server MUST immediately treat entries within
the area of replication as belonging to the parent area of replication
(if there is any). This includes replicating any pending replication
updates (those not yet replicated to other replicas) as if they
occurred under the parent area of replication, as well as preserving
any Lost and Found entries.
If a server receives a request to delete the replicationContext from an
area of replication, and there is a parent area of replication, the
Server MUST verify that these replicas are of the same type, and if
fractional, that the fractional entry specifications are identical. If
the replicas are not of the same type, the request MUST be failed with
resultCode unwillingToPerform.
5.15 Stop Replicating an Area of Replication.
This section describes how to stop replicating an area of replication.
At the end of the procedure, the subtree represented by the area of
replication will exist on one server, all replication agreements will
have been deleted, and the root of the area of replication will no
longer be an area of replication. The server on which the subtree will
remain is referred to as the surviving replica.
To stop replicating an area of replication, a client with
administrative authority should perform the following operations:
1. Halt replication
After halting, the client MAY optionally delete information by:
2. Delete all replication agreements (Section 4.10).
3. Delete all replicaSubentries under the area of replication
(section 4.7)
4. Issue a modifyRequest to the surviving server where the object
field is the DN of the area of replication, and the modifications
list consists of a single item, delete the attribute objectclasss
with value replicationContext.
Moats, et al Expires May 2002 [Page 11]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
5. Delete replicaContext from that server (Section 4.2)
6. Delete the area of replication from servers containing other
replicas (Section 4.4).
Note that client updates accepted on the non-surviving replicas during
this procedure may be lost (because they were not replicated to the
surviving server).
5.16 Suspending and Resuming Replication
To suspend replication of an area of replication to a specific server,
an administrative client can perform a modifyRequest of the
replicaSubentry, with a modification list replacing the replicaOnline
attribute with the value false. Performing this request on the
specified server causes the server to stop accepting or initiating
replication requests for that area of replication. This procedure can
also be performed on any other replica. The modifyRequest will be
replicated to other servers. When a server other than that specified
by the replicaSubentry receives the request the server MUST stop
sending replication updates to the specified server. The unsent
changes MUST be saved until the replicaOnline attribute is chnaged to
true. Servers MUST continue to repond to replication updates sent from
the specified server.
To resume replication of an area of replication to a specific server,
an administrative client can perform a modifyRequest of the
replicaSubentry, with a modification list replacing the replicaOnline
attribute with the value false. This request must be performed on the
specified server, or it will not resume replication. This operation
may also be performed on other servers.
5.17 Convert a read-only replica to an updateable replica
TBD
5.18 Changing Replica URI on all servers handling an area of
replication
The client issues this request to the server whose address has been
changed, which replicates it to the other replicas like other client
updates. It may be necessary to issue the same request to other
replicas, for example, when the server does not have proper replication
agreements to fully replicate this change (as in consumer initiated
replication).
5.19 Postpone a Replica Cycle to a Later Time
TBD
5.20 Examine Replication Audit History on a Server
TBD
5.21 Compare Two Replicas on Two Servers for Differences
TBD
5.22 Fix an Entry Without Triggering Replication
When conflicts cause entries to be put in the Lost+Found area, the
administrator needs a mechanism to make appropriate changes. These
Moats, et al Expires May 2002 [Page 12]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
changes should not trigger replication since they are used to fix
previous replication problems. In addition, these changes may include
fixes to UUIDs, CSNs, or other control data that cannot be changed
using normal LDAP operations.
TBD
5.23 Check Reported Schema Mismatches Discovered During Replication
TBD
5.24 Adding a new directory server to a replica group and initializing
the contents
In this case, the client:
1. Creates the replicaContext on the new server (section 4.1)
2. Copies the base entry for the area of replication from a source to
the target (section 4.5)
3.
Create the entries for the new server on all servers in the replica
group (section 4.6)
4.
Create the entries for the existing replica group servers on the new
(section 4.6)
5.
Create the replication agreement on all servers (section 4.9)
6.
Client issues a "Initiate Full Update" request to a full replica for
the new replica -- or new replica requests consumer initiated full
update
5.25 Restore from the master failure in a single-master system
TBD
6 Formal Specifications
The Replica Management features depend heavily on defined LDAP and LDUP
structure, operations, and data formats. But some changes will be
needed to accommodate Replica Management. All these changes are pulled
together in this section for easy reference.
6.1 New/Modified Object Classes
TBD
6.2 New/Modified Attributes
TBD
6.3 New/Modified Extended Operations
Trigger Replica Operation
TBD
Moats, et al Expires May 2002 [Page 13]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
6.4 New/Modified Replication Primitives
TBD
7 Security Considerations
In all cases, it is assumed that the client establishes a connection to
the LDAP server and SHOULD authenticate using a recommended
authentication method [RFC2829] that establishes the identity of the
client user and SHOULD provide for connection integrity. In
deployments where the underlying network service is vulnerable to
eavesdropping and clients are intending to retrieve sensitive server
credentials, the chosen method SHOULD also provide for encryption of
data in transit.
In general, where the client is unaware of any network level protection
services, it is RECOMMENDED that the client immediately after
connection establishment invoke Start TLS to establish connection
integrity and confidentiality, and follow this by authentication by one
of:
- the "DIGEST-MD5" SASL mechanism,
- the "simple" authentication choice, or
- the "EXTERNAL" SASL mechanism if the client provided its
certificate during TLS establishment.
The client MAY determine the supported authentication mechanisms of the
server from the supportedSASLMechanisms attribute of the root DSE after
Start TLS has been invoked, and use this to decide whether to use
DIGEST-MD5 or EXTERNAL. See [RFC2830] for more information on TLS.
8 Acknowledgements
Thanks to Mark Wahl and Ed Reed for providing a lot of the initial
text.
This document is a product of the LDUP Working Group of the IETF. The
contributions of its members are greatly appreciated.
9 References
[Arch] J. Merrells, E. Reed, U. Srinvasan, "LDAP Replication
Architecture", draft-ietf-ldup-model-01.txt.
[InfoMod] E. Reed, "LDAP Replication Information Model", draft-ietf-
ldup-infomod-00.txt
[RFC2119] S. Bradner, "Key Words for Use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL Morgan, "Authentication
Methods for LDAP", RFC 2829, May 2000.
Moats, et al Expires May 2002 [Page 14]
INTERNET DRAFT Mandatory LDAP Replica Management November 2001
[RFC2830] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access
Protocol (v3): Extension for Transport Layer Security", RFC 2830, May
2000.
Author's Addresses:
Ryan Moats
Lemur Networks, Inc.
Email: [email protected]
Rick Huber
AT&T Laboratories
Email: [email protected]
John McMeeking
IBM
Email: [email protected]
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Moats, et al Expires May 2002 [Page 15]