Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D

From: John Strassner <[email-masked]>
Date: Sun, 18 Feb 2001 21:46:44 -0800

I disagree on several counts.

First, if we start singling out particular types of information that can or 
can not be replicated, where do we stop?

Second, please stop using the term "passive data" as no one on this list 
has defined it in an unambiguous and satisfactory manner. It is impossible 
to consider using LDUP in this fashion until a definition for this term 
that we can all agree with is offered and agreed to.

Third, what you're basically saying is that we should close up shop until 
LDAPext has finished a standards-track access control model RFC. I don't 
agree at all. First of all, RFC 2251, section 3.2, says that "Servers which 
perform caching or shadowing MUST ensure that they do not violate any 
access control constraints placed on the data by the originating server."

Finally, we have a lot of work to do in this wg, and all of it hinges on 
this draft. We can't go forward with anything else until this draft goes 
forward. I don't think our ADs nor the wg as a whole wants to wait any longer.

John

At 11:18 PM 2/16/2001 -0800, Paul Leach wrote:
>You're right -- it isn't the job of LDUP to say how to replicate ACLs.
>
>However, it is appropriate to point out that until such a standard
>exists, LDAP conformant directories will not be able to be replicated
>via LDUP.
>
>So, one of the requirements for replication between multiple standards
>conformant LDAP servers using LDUP is that said servers not implement
>anything other than standard LDAP acess to totally passive data.
>
> > -----Original Message-----
> > From: Ryan Moats [mailto:[email-masked]]
> > Sent: Friday, February 16, 2001 5:57 PM
> > To: Mark Brown (REDMOND); Ryan Moats; Richard V Huber;
> > [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> >
> >
> > John, Chris, do you have a sense of the working group from
> > the list messages?  I've not seen enough reaction to see
> > whether we've got rough consensus one way or another, and
> > I'm worried that this discussion threatens to become a
> > rat-hole.
> >
> > See <rm^2>...</rm^2> below...  Ryan
> >
> > -----Original Message-----
> > From: Mark Brown (REDMOND) [mailto:[email-masked]]
> > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> >
> >
> >   <rm> ...
> >   ... A standard mechanism for directory replication in a
> >   multi-vendor environment is critical to the continued
> >   success of LDAP in the market place. This document sets
> >   out the requirements for replication between multiple
> >   standard-conformant LDAP servers. ...
> >   ^^^^^^^^^^^^^^^^^^^ <- new text
> >   ... </rm>
> >
> > An LDAP server that implements semantics not
> > mentioned in the LDAP RFCs does not thereby
> > become non-standard-conformant.
> >
> > <rm>Never said it didn't</rm>
> >
> > For instance, most LDAP servers today implement an
> > access control scheme. No access control scheme
> > is mentioned in the LDAP RFCs. Yet LDAP servers
> > that implement access control are conformant with
> > the LDAP standard.
> >
> > <rm^2>In the absence of an LDAP standard for access
> > control, you can't have interoperability of access
> > control in the IETF sense.  However, I am not willing
> > to delay this document for something that is the
> > responsibility of another working group.  The proper
> > IETF procedure (as I understand it) is for this document
> > to go forward and it become the responsibility of
> > the access control draft authors to include the replication
> > implications of the new standard.  That avoids
> > a "boil the ocean" conundrum preventing progress.</rm^2>
> >
> > Similarly, a server that implements internal
> > triggers for the purpose of maintaining certain
> > invariants in the directory can conform with
> > the LDAP standard.
> >
> > <rm^2>Again, in the absence of an LDAP standard for internal
> > triggers you can't have IETF interoperability to
> > replicate that information with LDUP. If you want
> > interoperability in replicating internal triggers,
> > the proper process is to develop an RFC and address
> > the issues there.</rm^2>
> >
> > LDUP is designed to solve the problem of replicating
> > the representations of directories. But the
> > correspondence between these representations and the
> > LDAP protocol is not a simple one in general -- it is
> > only simple for directories that are completely passive
> > stores. When LDUP is used to replicate (the representations
> > of) non-passive stores, it is up to the developers of those
> > stores, not LDUP, to define how to achieve
> > interoperability. (Most likely, they'll do this pairwise.)
> >
> > Readers of the requirements draft, even with your
> > proposed amendment, are likely to think that LDUP
> > is meant to provide interoperability between directories
> > rather than between their representations. They are
> > likely to blame LDAP directory implementors for not
> > providing the same degree of interoperability as, say,
> > DNS server implementors do.
> >
> > As Kurt says down at the start of this thread, that's not
> > LDUP's job. It is worth adding a paragraph to the draft
> > so that it says so clearly.
> >
> > <rm^2>I claim we've addressed the issue already in -06
> > and with the suggested text above. Therefore, at
> > this point, I think I'd like to ask the chairs to get a
> > sense of the mailing list to see if we have rough-consensus,
> > because I can see argument turning into a rat-hole.</rm^2>
> >
> > --mark
> >
> > -----Original Message-----
> > From: Ryan Moats [mailto:[email-masked]]
> > Sent: Friday, February 16, 2001 12:40 PM
> > To: Mark Brown (REDMOND); Richard V Huber; [email-masked];
> > [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> >
> >
> > See <rm>...</rm> below... Ryan
> >
> > -----Original Message-----
> > From: Mark Brown (REDMOND) [mailto:[email-masked]]
> > Sent: Tuesday, February 13, 2001 8:38 PM
> > To: Richard V Huber; [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> >
> >
> > So sorry -- I missed those changes when the -06 version came out.
> >
> > Shortening my suggested addition seems like a good idea.
> >
> > <rm>Good</rm>
> >
> > But the intent of my suggestion was to set a clear requirement for
> > LDUP's ability to provide interoperability. That way, as other LDUP
> > drafts progress, we'll be able to tell if they are meeting the goal
> > set in the requirements.
> >
> > <rm>I personally am willing to do the following text adjustment,
> > (the other authors still get to comment)...
> >
> >   ... A standard mechanism for directory replication in a
> >   multi-vendor environment is critical to the continued
> >   success of LDAP in the market place. This document sets
> >   out the requirements for replication between multiple
> >   standard-conformant LDAP servers. ...
> >   ^^^^^^^^^^^^^^^^^^^ <- new text
> >
> > Beyond this, I disagree that LDUP requirements need to be stated
> > to cover items that don't have an LDAP standard yet.  Any new LDAP
> > standard should cover the impact of replication on that standard,
> > not the other way around.</rm>
> >
> > Since we are doing this work in the IETF, interoperability should be
> > one of the primary concerns of the work.
> >
> > But the proposed text
> >
> > :   Interoperability of replicas between directory servers may be
> > limited
> > :   by servers that implement semantics that go beyond what the LDAP
> > :   access protocol defines.  Examples (not an exhaustive
> > list) of such
> > :   semantics include: (1) replication among directory servers with
> > :   different access control systems/semantics may compromise
> > directory
> > :   security, and (2) replication among directory servers
> > with different
> > :   application trigger semantics may compromise directory data
> > :   integrity.
> >
> > does not set a clear requirement for LDUP's ability to provide
> > interoperability. It says that when we are done designing LDUP, it is
> > OK that certain directory servers will not be able to replicate. It
> > does not say that for the LDUP design to be considered a viable IETF
> > standard, it is necessary that there is some pair of directory
> > servers (not from the same code base) that LDUP enables to replicate.
> >
> > Of course, we don't want to state such a goal in terms like "LDUP will
> > enable OpenLDAP and the Siemens DS to replicate," we want to state the
> > goal in terms of the functional characteristics of a pair of systems
> > that
> > are able to replicate. That's what my suggested text tried to do.
> >
> > How about this:
> >
> > : The goal of LDUP is to support replication between directory servers
> > : that each implements a passive store fully described by its LDAP
> > interface.
> > : "Passive store" means that the servers are limited to
> > storing entries
> > that
> > : come in via LDAP and retrieving those identical entries later in
> > response
> > : to LDAP requests. The entire semantics of such a store is defined by
> > its
> > : LDAP interface. Any restrictions on what the server can
> > store must be
> > : expressed in the server's schema, and any restrictions on the access
> > that
> > : clients have to the store must be expressed in terms of a
> > standardized
> > : LDAP access control scheme.
> > :
> > : LDUP is not required to support replication between directory
> > : servers that each implements an active store extending LDAP
> > : semantics with non-standard access control rules or with triggers.
> > : Examples of triggers include password length/complexity policies and
> > : automatic storage of secure password hashes instead of passwords.
> >
> > --mark
> >
> > -----Original Message-----
> > From: Richard V Huber [mailto:[email-masked]]
> > Sent: Tuesday, February 06, 2001 12:52 PM
> > To: [email-masked]; [email-masked]; Mark Brown (REDMOND)
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; [email-masked]
> > Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> >
> >
> > We addressed these issues in version -06, though we cut down the text.
> >
> > Here is the summary that was included when I sent version -06 to the
> > list.  I haven't seen any comments on it since it was posted.
> >
> > : Internet Drafts Editor -
> > :
> > : Please publish the draft below as draft-ietf-ldup-replica-req-06.txt
> > : It replaces the -05 draft from November.
> > :
> > : LDUP Mailing list -
> > :
> > : The attached version of the draft incorporates changes to
> > address the
> > : comments from San Diego.  We trimmed Mark's proposed
> > changes since we
> > : were concerned that they went into too much detail that
> > wasn't really
> > : LDUP related.
> > :
> > : Our specific changes are:
> > :
> > : Insert the following as the last paragraph in Section 3:
> > :
> > :   Interoperability of replicas between directory servers may be
> > limited
> > :   by servers that implement semantics that go beyond what the LDAP
> > :   access protocol defines.  Examples (not an exhaustive
> > list) of such
> > :   semantics include: (1) replication among directory servers with
> > :   different access control systems/semantics may compromise
> > directory
> > :   security, and (2) replication among directory servers
> > with different
> > :   application trigger semantics may compromise directory data
> > :   integrity.
> > :
> > : Add the following at the end of the Security Considerations Section:
> > :
> > :   As noted in Section 3, security may be impacted when replicating
> > :   among servers that implement non-standard extensions to basic LDAP
> > :   semantics.  Access control is one common case which affects
> > security;
> > :   work to address this issue is documented in RFC 2820 [RFC2820].
> > :
> > : Add the new reference to the References:
> > :
> > :   [RFC2820]  E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access
> > :   Control Requirements for LDAP", RFC 2820, May 2000.
> > :
> > : Change the draft number and the publication and expiration dates.
> > :
> > : As always, please send comments to the list.
> >
> > Rick Huber
> >
> > --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
> > : Subject: RE: WG Last Call on the LDAPv3 Directory Replication I-D
> > : Thread-Topic: WG Last Call on the LDAPv3 Directory Replication I-D
> > : Thread-Index: AcCP5HY9fw2/PIuYQC+oULzgUxaapgAgz+xQ
> > : From: "Mark Brown (REDMOND)" <[email-masked]>
> > : To: "John Strassner" <[email-masked]>, <[email-masked]>
> > : Cc: "Chris Apple" <[email-masked]>,
> > :         =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>
> > : Sender: [email-masked]
> > :
> > : The LDAPv3 Directory Replication Requirements I-D document does
> > : not address the interoperability limits issue that we discussed
> > : in December-January.
> > :
> > : I append the most recent message on the topic.
> > :
> > : --mark
> > :
> > : -----Original Message-----
> > : From: Mark Brown (REDMOND)
> > : Sent: Thursday, January 11, 2001 7:41 PM
> > : To: Ellen Stokes; Kurt D. Zeilenga
> > : Cc: [email-masked]
> > : Subject: RE: interoperability limits: proposed addition to
> > : draft-ietf-ldup-replica-req-05.txt
> > :
> > : Oops, I left off the examples. Let's try again:
> > :
> > : I suggest inserting the following material right after
> > : the first paragraph of Section 3 ("The Models") of the
> > : requirements draft (just before the sentence "There are five
> > : data consistency models.")
> > :
> > : --mark
> > :
> > : * * * * *
> > :
> > : The objective is limited to replication between directory servers
> > : that implement a passive store fully described by its LDAP
> > : interface. "Passive store" means that the servers are limited to
> > : storing entries that come in via LDAP and retrieving those entries
> > : later in response to LDAP requests. The entire semantics of
> > : the passive store is defined by its LDAP interface. Any
> > : restrictions on what the server can store must be
> > : expressed in the server's schema, and any restrictions on the
> > : access that clients have to the store must be expressed in terms
> > : of a standardized LDAP access control scheme. This is in
> > : contrast to an "active store" that implements triggers
> > : or other rules that extend the semantics of entries beyond
> > : what's implied by LDAP. Replication between such active
> > : stores should be specified in extensions to LDUP.
> > :
> > : Here are some examples of ways in which directory servers
> > : implement semantics that go beyond what the LDAP access
> > : protocol defines:
> > :
> > : * Access control. LDAP does not currently define an access
> > :   control scheme. (The ldapext WG is working to extend LDAP
> > :   with an access control scheme.) Most directory servers
> > :   implement an access control scheme.
> > :
> > :   Replication between directory servers with different
> > :   access control schemes would compromise directory security,
> > :   so such replication is not supported by LDUP.
> > :
> > : * Password policy. Some directory servers restrict changes
> > :   to password attributes, requiring that the new password
> > :   value conform to a specific security policy (e.g. the value
> > :   is sufficiently long and complex.) Doing so reduces the
> > :   security risk associated with passwords that are easy to
> > :   attack.
> > :
> > :   Replication between directory servers with different
> > :   password policies (e.g. one server implements a password
> > :   policy and a second server implements no policy) would
> > :   compromise directory security, so such replication is not
> > :   supported by LDUP.
> > :
> > : * Password hashing. Some directory servers don't store a user's
> > :   password directly, but instead store one or more secure
> > :   hashes of the password. Doing so makes it less likely that
> > :   anyone (even an administrator) can discover the password.
> > :
> > :   Replication between a directory server that stores passwords
> > :   and a directory server that stores only hashes will compromise
> > :   directory integrity, causing authentications to fail
> > :   unexpectedly, so such replication is not supported by LDUP.
> > :
> > : * * * * *
> > :
> > : -----Original Message-----
> > : From: Mark Brown (REDMOND)
> > : Sent: Thursday, January 11, 2001 3:10 PM
> > : To: Ellen Stokes; 'Kurt D. Zeilenga'
> > : Cc: [email-masked]
> > : Subject: RE: interoperability limits: proposed addition to
> > : draft-ietf-ldup-replica-req-05.txt
> > :
> > :
> > : We appear to be in total agreement.
> > :
> > : So I suggest inserting the following paragraph right after
> > : the first paragraph of Section 3 ("The Models") of the
> > : requirements draft (just before the sentence "There are five
> > : data consistency models.")
> > :
> > : --mark
> > :
> > : * * * * *
> > :
> > : The objective is limited to replication between directory servers
> > : that implement a passive store fully described by its LDAP
> > : interface. "Passive store" means that the servers are limited to
> > : storing entries that come in via LDAP and retrieving those entries
> > : later in response to LDAP requests. The entire semantics of
> > : the passive store is defined by its LDAP interface. Any
> > : restrictions on what the server can store must be
> > : expressed in the server's schema, and any restrictions on the
> > : access that clients have to the store must be expressed in terms
> > : of a standardized LDAP access control scheme. This is in
> > : contrast to an "active store" that implements triggers
> > : or other rules that extend the semantics of entries beyond
> > : what's implied by LDAP. Replication between such active
> > : stores should be specified in extensions to LDUP.
> > :
> > : * * * * *
> > :
> > : --mark
> > :
> > : -----Original Message-----
> > : From: Kurt D. Zeilenga [mailto:[email-masked]]
> > : Sent: Tuesday, January 09, 2001 4:54 PM
> > : To: Mark Brown (REDMOND)
> > : Cc: Ellen Stokes; [email-masked]
> > : Subject: RE: interoperability limits: proposed addition to
> > : draft-ietf-ldup-replica-req-05.txt
> > :
> > :
> > : Mark,
> > :
> > : Replication in the face of triggers or any other LDAP extension
> > : should be specified in extensions to the LDUP.
> > :
> > : LDUP should assume 'passive' servers as this, I believe, is the
> > : LDAP/X.500 data model.  That is, servers should not muck with
> > : user data.
> > :
> > : Kurt
> >
> >

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 19 Feb 2001 15:02:44 -0800

At 09:46 PM 2/18/01 -0800, John Strassner wrote:
>First, if we start singling out particular types of information that can or can not be replicated, where do we stop?

Personally, I think LDUP MUST support userApplication attributes,
SHOULD support subtypes, SHOULD support ;binary, MAY support
language tags.  I believe LDUP SHOULD support replication of directoryOperation attributes listed in RFC 2251, 3.2.1.  Support
for other directoryOperation and distributedOperation attributes
SHOULD be handled by extension.  There likely SHOULD be some
requirements upon subschema entries (or subentries) as well (but
this gets messy and may be better left as an extension).

>Second, please stop using the term "passive data" as no one on this list has defined it in an unambiguous and satisfactory manner. It is impossible to consider using LDUP in this fashion until a definition for this term that we can all agree with is offered and agreed to.

I agree.  I believe we should use the term "userApplication" attribute.
This is well defined.

>Third, what you're basically saying is that we should close up shop until LDAPext has finished a standards-track access control model RFC. I don't agree at all. First of all, RFC 2251, section 3.2, says that "Servers which perform caching or shadowing MUST ensure that they do not violate any access control constraints placed on the data by the originating server."

Though I believe LDUP documents MUST address this issue, I believe
it fine for LDUP to say that it does not resolve this issue and that
deployers of LDUP must ensure that replicas do not violate these
constraints.

There should not be any LDUP dependency upon LDAP ACM as LDAP
ACM is:
        an elective extension,
        not the only ACM,
        doesn't itself ensure the constraints are met.

>Finally, we have a lot of work to do in this wg, and all of it hinges on this draft. We can't go forward with anything else until this draft goes forward. I don't think our ADs nor the wg as a whole wants to wait any longer.

I, too, would like to see the requirements I-D progressed soon.
I note most of the issues are in "justification" portions of the
I-D, not the actual requirements...  I would hope we could reach
consensus on the requirements soon.  If not, we are doomed.