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

From: "Mark Brown (REDMOND)" <[email-masked]>
Date: Thu, 11 Jan 2001 19:40:35 -0800

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: "Albert Langer" <[email-masked]>
Date: Fri, 12 Jan 2001 18:35:41 +1100

[Mark]

[Albert]
Essentially this simply means that LDUP is pretty useless until
an access control scheme is specified. Problem is that without
atomicity, it will remain pretty useless when the current drafts
for access controls are finalized. But that's another topic - 
still waiting for promised response from Chris.

[Mark]

[Albert]
This may be overstated. It might be possible to instead deal with
this problem by requiring that LDUP protocols provide special case
handling for schema elements that are designated as passwords by some
per server entry that specifies a password policy identifier, so
that other servers will not make accessible (but will still forward)
replication of those attributes when they do not understand and
implement the required policy.

That could be messy and could still result in flaky behaviour of passwords
being available from some servers and not from others, but it would
not compromise directory security and therefore would not be a
complete show-stopper, since implementations suffering could fix the
problem incrementally instead of LDUP being completely useless (ie
unable to replicate between major implementations since they 
have different password policy techniques).

Requirement should be for mandatory disclosure of password policy
mechanisms by implementations claiming conformance, with some sort
of IANA registry.

[Mark]

[Albert]
Again, it may be possible to special case this rather than declaring
that LDUP is fundamentally incapable of providing interoperability
between major directory implementations.

[Mark - from previous message]

[Albert]
I'm not clear about this. Triggers are not extensions to LDUP,
but to LDAP, since they are equally relevant without replication.
There are LDAP extensions specifying drafts or standards for an
LDAP client to subscribe to notifications about particular types
of changes. If that, or any other mechanism results in an application
external to the directory service making changes to directory entries,
then those changed entries must be replicated normally.

It is not clear to me that the fact that some implementations actually make
such changes internally within the directory server rather than via an
external application makes any difference. In principle it is still
something outside the directory service (as specified by LDAP and X500)
making changes to directory entries. Conformance to LDUP simply requires
that those changes, however made, be replicated.

eg if Microsoft Active Directory "backlinks" are visible in the
replication schema, then conformance would require that you
replicate the changes to the backlink as well as the forward
link via LDUP, even though replication to other Microsoft
servers within the replication area could more efficiently
just rely on each server performing an update to the backlink
independently when the forward link is changed.