Subject: LDAP subentry alignment with X.500 subentry

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 03 Jul 2000 09:25:32 -0700

I believe 'LDAPsubentry' should be replaced with with 'subentry' and
defined such that it closely modelled after X.500.

1) subentries should have a subtree specifier such that they are more
useful for specification of ACI subentries.

2) subentries should be visible based upon presence of a subentries control,
not a filter components.  For example:
  (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*))

Should the subentry be visible or not?   There are reasonable arguments
for both yes and no.

I primarily make these suggestions because I believe these changes would
make subentries within LDAP more usable, in particular, when used in
support of the access control model.

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Fri, 07 Jul 2000 08:10:36 -0700

> useful for specification of ACI subentries.

The X.500 subtree specifier is rich and therefore fairly complex to
implement.  That doesn't mean we shouldn't adopt it, but it does mean we
should consider the impact.

> Should the subentry be visible or not?   There are reasonable arguments

But controls are of course more costly for clients and servers to
implement.  What problem are you trying to solve?  As currently defined,
clients that have knowledge of LDAPsubentries can retrieve them and
those that do not won't.  That meets my needs.

> support of the access control model.

Interesting.  Before we throw out the simple LDAPsubentry that Ed has
defined, I think someone should list the additional requirements that
are needed for the access control effort to successfully use subentries.

--
Mark Smith
iPlanet

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 07 Jul 2000 09:01:37 -0700

>should consider the impact.

We should consider the impact of implementing something different.
LDAP is an access protocol to an X.500 directory.  Each divergence from
the X.500 information/service models makes increasing difficult to
implement servers which supports both LDAP and DAP
and gateways between LDAP and DAP.

>implement.

I disagree.  A control is actually quite simple to implement and rather
cheap (as demonstrated by ManageDsaIT).  Interpeting filter side effects
in complex and often leads to inconsistent implementations due to
ambiguity in the specification of these side effects (as demonstrated
by matched-00).

The advantage of a control is it provides an unambiguous mechanism to
enable the behavior.

> What problem are you trying to solve?

In terms of the filter comment: ambiguity of specification, consistency
of implementation.

In terms of subentry v. entry comment: unnecessary incompatible divergence
from X.500.

>As currently defined,
>those that do not won't.

Does the filter above have the side effect of making subentries visible
or not? 

>are needed for the access control effort to successfully use subentries.

To turn the tables a bit, before we through out X.500 subentry, I think
someone should list LDUP (or other) requirements which the X.500
subentry mechanism is inadequate.

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Fri, 07 Jul 2000 19:54:39 +0200

Mark,

I would say that the complexity of the X.500 style specifier would be a barrier
to it's adoption for the LDAP access control model.
So I would say some simplified subtree specifier would be preferable (base,
onelevel, subtree ?).

Even ignoring the subtree specifier there are cons associated with  putting acis
into subentries compared to just storing them as attributes--for example you need
to control access to the subentries which, becuase subentries do not behave like
ordinary entries, requires at least one additional aci attribute (something like
entryACI or subEntryACI).

Rob.

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 10 Jul 2000 13:07:22 +1000

Rob,

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rob Byrne - Sun
> Microsystems
> Sent: Saturday, 8 July 2000 3:55
> To: Mark C Smith
> Cc: Kurt D. Zeilenga; [email-masked]; [email-masked]; Ed
> Reed
> Subject: Re: LDAP subentry alignment with X.500 subentry
> 
> 
> 
> Mark,
> 

Would it be acceptable to use the X.500 SubtreeSpecification but
constrain it for use in LDAP ? I would rather deal with a subset of
existing functionality than a separate mechanism to do the same thing.
It would also provide an obvious upgrade path in future versions of LDAP
by relaxing the constraints, if it proves desirable.

The simple subtree specifier above would be equivalent to providing
only the "minimum" or "maximum" component of a ChopSpecification, e.g.

base equates to "{ maximum 0 }"
onelevel equates to "{ minimum 1, maximum 1 }" or maybe "{ maximum 1 }"
subtree equates to "{ }"

All other fields being absent.

Regards,
Steven

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Mon, 10 Jul 2000 10:51:18 +0200

Stephen,

If we were to use subentries to store aci items then your
"restriction" proposal sounds like a good approach.

However, it could be argued that it would be useful to extend the X.500
subtree specifier to allow the refinement to be a generic filter (not just
on the objectclass attribute).

So, on the subject of a subtree specifier for LDAP, then wrt the X.500
specifier I would venture something like: drop the chops (in favour of a
start point and base, onelevel and subtree) and allow the refinement to be
a generic filter (not just on the objectclass).

However, I would also like to see a discussion of why we should put acis
into subentries rather than just store them as ldapACI attributes in
entries.  What are the pros and cons ?

Cheers,
Rob.

---

From: "Albert Langer" <[email-masked]>
Date: Tue, 11 Jul 2000 16:37:04 +1000

[RB]

Stephen,

Cheers,
Rob.

[AL]
Extending X.500 subtree specifier to allow a generic filter (not just on
objectclass attribute) would be a bad idea, for reasons explained below. I
agree with Steve's proposal to use a subset of X.500, not a superset. This
subset should be the minimum necessary to support replication subentries
(which isn't much), but using the generic standard so that implementors
needing more (eg for ACI) don't have to duplicate effort.

First, apologies to all, and especially to Steve, for long delay responding
to Steve's careful response re MDCR etc. Will be replying in detail but had
to put it aside and will still have to do so for at least another week due
to other priorities. (Got an excuse though, also waiting for authors reply
re requirements ;-)

Meanwhile, a quick point re this thread, as I can write about ACI and
subentries from off the top of my head, whereas multi-master replication is
HARD.

From above and other messages I suspect there may be some talking at cross
purposes re implementation issues vs protocol issues.

X.500 style subentries with chop sepecifications (by minimum and maximum
depth, plus named lower boundaries, plus arbitrary boolean filters on object
class only, can be implemented either by logic applied to traversal of the
path from the (administrative point of) the subentry or by logic applied to
COPIES of the subentry aci physically stored with the affected entry aci as
part of the entry. Both implementation methods can conform to the same
protocol standards that separate the administration of entry aci from the
administration of subentry aci.

The second method has all the administrative advantages mentioned by Alan,
because the subentry aci stored within an entry is administered from the
subentry point, independently of the entry aci. But it provides much greater
efficiency for read dominated directories at the expense of slower
application of changes to subentry aci (which are relatively infrequent).

eg Active Directory uses inheritance (from Admin points, not true named
subentries) to propagate the admin point aci downwards from the minimum
depth of the chop spec (limited to 0 or 1), to the maximum depth (limited to
0, 1 or infinite) with limited specification of object classes. Whenever the
inherited aci is changed, a write has to be made to EVERY affected entry,
which can be very slow for changes applied from high up, but the whole idea
of delegation is that such changes should be infrequent.

This is effectively the same as "base, one level and subtree" but with the
important addition of "below one level only". That enables the vitally
important specification of ACI that does not become effective until
propagated BELOW the point of application - effectively allowing a form of
unaffected subentries even when applied from an admin point (because
subentries have their own object class). The mechanism used in Active
Directory simply uses a bit to specify whether inherited aci is "inherit
only", in which case it is "dead" at the entry but becomes "live" when
copied to entries below. By changing this to an integer instead of a bit you
would get a chop min. Likewise a "don't propagate" bit cuts off further
copying for inheritance below. Changing that to an integer would give a chop
max.

There is no reason why the same general "inheritance by copy" approach could
not be used for true named subentry ACI (calculating inheritance from the
base instead of the subentry, even though the specification is named by the
subentry). Also the Active Directory limitation on chop specs and object
class filters seems related to transition from historical* NT/DCE security
descriptors rather than any inherent limitation in this model. (* Your
spelling of "historical" may vary, however the use of admin points instead
of named subentries can only be spelled one way, "hysterical").

The first method also has all the administrative advantages mentioned by
Alan, is simpler to implement and allows much faster changes since a change
only has to be written once, where it is physically stored only at the
subentry (or admin point). However it slows down reads and writes and
especially searches to the affected entries themselves and is therefore in
my view precisely the wrong optimization for directories. (Except where
there is so little delegation that all the non-entry ACI can be kept in RAM
anyway, as with many LDAP servers based on the U Michigan release with
highly centralized administration, even editing config files to change ACI).

It is also very intertwined with the naming structure. A regexp on naming
path for access control in a search would severely complicate the use of
aliases. That is why X.500 specifies ACI controls based on the unique
primary distinguished name of an entry, not on path names.

LDAP standards must not unnecessarily limit implementation choices. Filter
specifications on object classes work with either model, since every entry
knows its object classes and can easily calculate an arbitrary filter on
them quickly when determining visibility during searches. General filters
really only work with a traversal based implementation and are basically
just an attempt to substitute regexp evaluation on path names familiar to
centralized web administrators for a serious admin model that can actually
be delegated. The apparant additional flexibility is illusory since it
doesn't scale with real delegation, whereas the combination of min and max
depth, base, named lower bounds and object class filters does allow for
adequate delegation of directory access control domains independently of the
naming structure. Independence from the naming structure is essential for
scalable delegation.

This is also relevant to replication management issues when we move beyond
current scope and need to support opportunistic delegated replication
agreements for subsets of a replicated area, as mentioned in Alison's
contribution.

Most of this thread is more related to LDAP ACI extensions than to
replication. However the mechanism used for replication subentries should be
consistent with that used for any other purpose and should therefore be a
subset, not a superset.

Also, the generalization of subentries to families of related entries is
very relevant to dealing with atomicity and replication granularity issues.
As mentioned in MDCR attributes that need to be changeable independently and
concurrently at multiple replicas can be in separate subentries or child
entries of a parent family entry. Any such generalization of subentries need
only rely on object classes.

Most importantly, the multi-master replication of subentries MUST have
sufficient consistency properties to support their use for ACI. If the
replication mechanism is so broken that one has to rely on per replica
subentries to administer it, I don't see how it could possibly support
replicated access controls of any useful kind at all. This was also
mentioned in MDCR:

http://www.ietf.org/internet-drafts/draft-langer-ldup-mdcr-00.txt