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

From: Ellen Stokes <[email-masked]>
Date: Tue, 02 Jan 2001 12:46:48 -0600

Kurt,

At least part of your request for applicability (in your second
paragraph) will be covered in the Master-slave and multi-master
profile documents being authored by Rick Huber.

Ellen

At 06:43 PM 12/20/2000 -0800, Kurt D. Zeilenga wrote:
>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

---

From: "Mark Brown (REDMOND)" <[email-masked]>
Date: Mon, 8 Jan 2001 14:58:59 -0800

The essential question is, if I've got directory
servers A and B that both say they support LDUP,
how do I know that it is OK to hook them together
to replicate via LDUP?

Suppose for instance that server A has a
change-password trigger that recomputes password hashes,
and server B doesn't. And suppose I set up A and B to
replicate in a multi-master fashion. Then a user who
changes her password on server B won't be able to
authenticate on server A once server B replicates to
server A.

The problem created by replication goes beyond A and B
having "different capabilities." B has broken an
invariant that A was trying to maintain. B was working
before A came on the scene, but now B is broken.

So we need some way to characterize the servers that are
OK to hook together. Pairwise testing is obviously not
the answer. The suggestion I've made below is to limit LDUP
to "replication between directory servers that implement
a passive store fully described by its LDAP schema."
It seems quite plausible that we can achieve replication
between such servers without compromising their
functionality.

It may be possible to relax this suggested limit, but I'm
not sure how. If someone on the list knows how, they should
make a proposal. 

It seems pretty important to deal with this issue in the
requirements draft, since it is squarely a requirements
issue.

--mark

-----Original Message-----
From: Ellen Stokes [mailto:[email-masked]]
Sent: Tuesday, January 02, 2001 10:47 AM
To: Kurt D. Zeilenga; Mark Brown (REDMOND)
Cc: [email-masked]
Subject: Re: interoperability limits: proposed addition to
draft-ietf-ldup-replica-req-05.txt

Kurt,

Ellen

---

From: "Mark Brown (REDMOND)" <[email-masked]>
Date: Mon, 8 Jan 2001 16:27:06 -0800

I'm OK with either wording. The essential point is that
the application is quite strongly tied to the server, e.g.
is able to run code sychronously with request processing.

--mark

-----Original Message-----
From: John Strassner [mailto:[email-masked]]
Sent: Tuesday, December 26, 2000 3:46 PM
To: Mark Brown (REDMOND); [email-masked]
Subject: Re: interoperability limits: proposed addition to

Hmm, looks like my message got truncated, let's try again.

Hi Mark,

thanks for your note. One small suggestion: in your second
point about application triggers, you say "Directory servers
commonly integrate one or more specific applications". I
think you meant that one or more applications may integrate
with a given directory server, right?

regards,
John

----- Original Message -----
From: "Mark Brown (REDMOND)"
<[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 20, 2000 3:08 PM
Subject: interoperability limits: proposed addition to
draft-ietf-ldup-replica-req-05.txt

---

From: Ellen Stokes <[email-masked]>
Date: Tue, 09 Jan 2001 08:45:40 -0600

Mark,

The types of things you're talking about are typically ldap
extensions which are advertised in the root DSE by
(registered) OID.  So one could conclude that the replication
admin program could check to see that servers wanting to
replicate support the same extensions and allow the admin
to decide if to proceed in setting up the replicas.

I'm not sure I understand your 'passive store' statement.
Can you explain?  Is there a flip side you're thinking about
if the word passive changes to active?

Ellen

---

From: "Mark Brown (REDMOND)" <[email-masked]>
Date: Tue, 9 Jan 2001 15:05:33 -0800

None of the examples I've used are things you'd register
as LDAP extensions, because they have no effect on LDAP
as an access protocol:

  You can add access control capabilities to a directory
  server without extending LDAP -- clients perform LDAP
  requests, the server returns appropriate results
  (including LDAP result codes such as
  "insufficientAccessRights") after doing its internal
  access checking. No extension to LDAP. 

  A password policy can be viewed as a specialized access
  control rule -- the server simply fails password change
  requests that don't conform to the policy. All the LDAP
  client sees is a failed Modify request. No extension
  to LDAP.

  A change-password trigger that computes and stores
  password hashes is just a specialized Modify operation.
  The server stores the hashes in attributes that are
  well-known to the authentication packages that read them.
  These authentication packages cohabit the directory
  server process and read the hashes as needed via an
  internal API, not using LDAP. From the LDAP client
  perspective the change-password is just a Modify.
  No extension to LDAP.

In summary, the capabilities I'm talking about are things
that change the semantics of directory entries without
any impact on the access protocol.

In contrast, many LDAP extensions extend the access
protocol without changing the semantics of directory entries.
Their goal is to give you a way to express your access in a
more efficient way. Examples include a control that lets you
delete a sub-tree of entries in a single operation, and a
control that lets you "cursor" through the results of a search
(VLV.) There is no inherent difficulty replicating between a
server that supports (say) sub-tree delete and a server that
doesn't. So it would be unnecessarily restrictive to limit LDUP
to operate only between servers that implement the same LDAP
extensions.

The "passive store" characterization is meant to capture the
idea that the directory server stores the entries that come
in over the wire and retrieves them later -- period. You
can store something, then read it back later and you get
what you stored. Any restrictions on what you can store
must be expressed in the schema, and any restrictions on
who can do the writing and reading must be expressed in terms
of some standardized 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.

--mark

-----Original Message-----
From: Ellen Stokes [mailto:[email-masked]]
Sent: Tuesday, January 09, 2001 6:46 AM
To: Mark Brown (REDMOND); Kurt D. Zeilenga
Cc: [email-masked]
Subject: RE: interoperability limits: proposed addition to

Mark,

Ellen

At 02:58 PM 1/8/2001 -0800, Mark Brown (REDMOND) wrote:
> > >John Strassner suggested that I draft some material for inclusion
in
> > >The following material is meant to go right after the first
paragraph
>of
> > >  Such triggers enforce directory invariants that cannot be
expressed
>by
> > >  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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Jan 2001 16:54:16 -0800

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: "Mark Brown (REDMOND)" <[email-masked]>
Date: Thu, 11 Jan 2001 15:10:26 -0800

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

Mark,

Kurt