Subject: Re: interoperability limits: proposed addition to draft-ietf-ldup-replica-req-05.txt

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 20 Dec 2000 18:43:22 -0800

Unless the servers are truly equally capable, which is unlikely
if provided by different developers, the replicates will not
be equally capable regardless of well they interoperate with
each other and LDAP clients.  That is, application protocol
interoperability in no way guarantees that multiple implementations
behave in the exact same manner given exact replication of
information between them.

However, an applicability statement can help by narrowing
the options available to LDAP/LDUP implementors.  I believe the
LDUP WG should, in addition to specifying a replication protocol,
provide an applicability statement stating whatever additional
requirements there are of LDAP/LDUP servers such that each
replica is "equally capable" of processing an operation.

Kurt

At 03:08 PM 12/20/00 -0800, Mark Brown (REDMOND) wrote:
>In San Diego there was some discussion of the limits of LDUP
>interoperability.
>John Strassner suggested that I draft some material for inclusion in the
>requirements draft. Here it is.
>
>The following material is meant to go right after the first paragraph of
>Section 3
>("The Models"), and just before the sentence "There are five data
>consistency
>models."
>
>* * * * *
>
>The objective is limited to replication between directory servers that
>implement a passive store fully described by its LDAP schema. There are
>two
>ways in which directory servers commonly implement semantics that go
>beyond
>what the LDAP access protocol defines:
>
>* Access control. LDAP does not currently define an access control
>system.
>  (The ldapext WG is working to extend LDAP with an access control
>system.)
>  Most directory servers implement an access control system.
>
>  Replication between directory servers with different access control
>systems
>  will compromise directory security.
>
>* Application triggers. Directory servers commonly integrate one or more
>  specific applications. To achieve this integration the directory
>server
>  may intercept updates and run application-specific "trigger" code.
>  Such triggers enforce directory invariants that cannot be expressed by
>the
>  LDAP schema.
>
>  A simple trigger example is password policy enforcement. A directory
>server might
>  interpret a request to replace the current value of the userPassword
>attribute
>  with some new value as a request to first check that the new value
>conforms
>  to the server's password policy (e.g. the value is sufficiently long
>and complex)
>  before storing the new value. Using this trigger the directory server
>avoids the
>  security risk associated with passwords that are easy to attack.
>
>  A more complex trigger example is password hashing. A directory server
>might interpret
>  a request to replace the current value of the userPassword attribute
>with some
>  new value as a request to compute one or more secure hashes of the new
>value
>  and store these hashes in one or more attributes, storing no value in
>the
>  userPassword attribute. Using this trigger the directory server avoids
>the
>  security exposure of storing the plaintext password.
>
>  Replication between directory servers with different application
>triggers
>  will compromise directory integrity.
>
>* * * * *
>
>--mark