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

---

From: Rob Byrne - Sun Microsystems <[email-masked]>
Date: Thu, 13 Jul 2000 18:08:26 +0200

Ron/Alan/Albert,

Thanks for your responses.

There were two questions:

1. why can't we have generic filters to define the scope of subentries ?
2. what is so great about subentries anyway ?

For the first question, we have the following comments.

[Ron]

> I can so no purpose either for a general filter in a subentry of for scopes
>   in entry ACI.
>
>   The problem with the former is that, if the filter relates to
>   telephoneNumber, for example, and the user deletes this attribute from his
>   entry, the ACI may now behave unpredictably.
>

Ron, in our LDAP server  we provide this as a way to define entries to which
acis apply and this feature is used.  The effect is not unpredictable--the
behaviour of filters is well defined.  Though I agree that if the admin does
not define his policy well, the effect may be unexpected.  I think that the use
of this feature provides flexibilty but demands good management by the admin--I
guess it's a trade off.

[Albert]

>   them quickly when determining visibility during searches.
>

Albert, doesn't an entry know the other attributes that it contains as well and
so could evaluate an arbitrary filter ?

> General filters

Don't catch this--a general filter refers to values of attributes within the
entry, not the dn of the entry.  As I pointed out above, users of our directory
make use of this "illusion" all the time.

For the second question, "what is so great about using subentries for acis?", I
think Alan's response was clearest.  For my own benefit I've tried to distill
(quite a lot!) the main points to the points listed below.  I don't dispute
them, but I would say that the "aci attribute" approach also allows seperation
(it's an operational attribute) and delegation (you've got rights to that
attribute or not)...though not to the same extent as the subentry approach.

. the principal of seperating security information from that which it protects
is a good one and in particular, an aci in a subentry is "more seperate" than
an aci in a user entry.

. for delegation, the admin point/subentry approach offers more "levels of
delegation" because there are more components to it (admin points, subentries
and subEntryACI to protect subentries versus a single attribute).

. for distribution, if acis are clearly identified in subentries, then it is
easier to propagate this aci information to subordinate systems (if required)
than if it is distributed among the user entries.

Rob.

---

From: "Albert Langer" <[email-masked]>
Date: Fri, 14 Jul 2000 18:23:16 +1000

[Albert]

[Robert]
Albert, doesn't an entry know the other attributes that it contains as well
and so could evaluate an arbitrary filter ?
[Albert]
Sorry, I should have said "the (structural) object class of an entry is
fixed and therefore the set of applicable subentries does not need to be
recalculated on every search". With general filters such a calculation would
be needed on every search, for every subentry that has a parent within the
base of the search applied to every entry within the scope of the search.
This is multiplying the cost of a search by the number of potentially
applicable subentries (not just the number of actually applicable
subentries).

[Albert]  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
[Robert]
Don't catch this--a general filter refers to values of attributes within the
entry, not the dn of the entry.  As I pointed out above, users of our
directory make use of this "illusion" all the time.
[Albert]
Whoops, I was arguing against the use of regexp path based ACIs as used in
UMich derived implementations. As you say, this is irrelevant to your
suggestion for (entry) attribute based filters (assuming that a "generic"
filter does not treat dn as an attribute). That's what comes from responding
from "off the top of my head". My other argument above still stands.

[Robert]  For the second question, "what is so great about using subentries
for acis?", I think Alan's response was clearest.  For my own benefit I've
tried to distill (quite a lot!) the main points to the points listed below.
I don't dispute them, but I would say that the "aci attribute" approach also
allows seperation (it's an operational attribute) and delegation (you've got
rights to that attribute or not)...though not to the same extent as the
subentry approach.
[...]

[Albert] I've just realised this topic is across ldap-ext as well as ldup.
I'm not subscribed to ldap-ext and don't have time to be at the moment, so
I'm not plannning to comment further.

For the record though, I believe that:

1. The LDAP subentry proposal is adequate for current LDUP needs. It may be
more than adequate because allowing nested families of subentries may not be
strictly necessary since the replication agreements children of subentries
contain the dn of the replica they apply to. It also appears to still rely
on special case semantics for the meaning of a child subentry of replica
entry. Changing the structure rules is not a minor variant and if done I
would prefer to see it done more fully as in:

 Chadwick, D.W., "Compound (Families of) Entries", Internet-Draft,
      draft-chadwick-families-00.txt, (expired) 5 December 1999.

Ed's argument for a subset of X.500 rather than a superset is convincing.
Its application to a final call for endorsement of a superset by varying
structure rules is not convincing. But somebody has to either object now or
hold their peace. I'm sticking to my objection to the replication
requirements but holding my peace on subentries. If you want a different
superset you need to object now.

2. There will be future LDUP needs for subtree specifications related to
management of the creation of new replication areas. However this is beyond
the current scope.

3. LDAP-EXT ACI ought to have requirements for Directory Access Control
Domains, which need subentry specifications with object class filters. Not
having them severely complicates simple things like delegating management of
printers to printer operators across organizational unit boundaries as well
as across both distribution and replication boundaries. I pointed this out
at the Melbourne IETF but I don't have time to pursue it.

4. Issues like LDAP subentries are quite naturally across both WGs. In my
view there is a vital need for coordination of issues like transactions and
ACI across both groups. The current replication proposals from LDUP will
impede if not prevent any deployment of transactions. This however may not
matter as they will also not meet any reasonable requirements for ACI and
therefore are unworkable anyway. This is independent of whether ACI should
include DACDs. Any workable ACI MUST be replicated atomically and the
current LDUP proposals fail to achieve that, so discussion of attempts to
standardize subentries for ACI as well as for replication within LDUP are
rather pointless.

5. LDAP-EXT has, and should therefore state, a clear requirement for atomic
replication of ACI attributes so that LDUP could stop trying to avoid the
issue. Despite the overlap of authorship of the two requirements documents
there is no indication of any understanding of the impact of non-atomicity
on ACI.

Anyone in LDAP-EXT interested in this should look at my objection and
alternative to the current LDUP proposals:

Please send or CC any comments to LDUP as I won't see them in LDAP-EXT.

Seeya, Albert

---

From: "Steven Legg" <[email-masked]>
Date: Mon, 17 Jul 2000 13:08:52 +1000

Albert,

> [mailto:[email-masked]]On Behalf Of Albert Langer
> Sent: Friday, 14 July 2000 18:23
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: LDAP subentry alignment with X.500 subentry

[snip]
 
> applicable subentries (not just the number of actually applicable

The specificationFilter of a SubtreeSpecification applies to the
objectClass attribute rather than the structuralObjectClass. Since the
objectClass can contain optional auxiliary object classes that come
and go, a conformant X.500 implementation already has to deal with the
situation where the set of applicable subentries changes.

Some of our customers need to be able to set access controls based on
the non-objectClass attributes of the entry. The way we have achieved
this with X.500 basic access control is to define an auxiliary object
class, with no mandatory or optional attributes, that we use to tag
entries satisfying an implied filter on the entry contents.
SubtreeSpecifications then reference the auxiliary class in their
specificationFilters. The auxiliary class tagging has to be maintained
manually. Being able to filter on arbitrary entry contents in the
specificationFilter would be better.

[snip]

Regards,
Steven

---

From: "Albert Langer" <[email-masked]>
Date: Mon, 17 Jul 2000 23:46:40 +1000

Steven,

Thanks for:

a) The correction below.
b) The explanation of why the non-restriction to structural classes is
useful.
c) The explanation of why general filters would be more useful.

Clearly I was wrong about the restriction to object class avoiding any need
to dynamically track which DACDs an entry is in, though I still think it
might be simpler and more efficient than for a general filter, eg some
implementations only having to recalculate when an entry changes its object
class attribute (rarely), rather than for any change.

I'm still not convinced about the advantage of c) over b), although this
certainly does at least diminish one argument against c).

Other reasons are:

1. General principle that LDAP should remain "lighter" than X.500 and
compatible with it. Therefore any superset variations should be demonstrably
necessary, eg to simplify something else, not just desirable. Proper
subentries are demonstrably necessary to simplify access control. As Kurt
pointed out, not providing them will just result in more complex ways of
doing the same thing being required anyway. But "enhanced" subentries are
not demonstrably necessary.

2. What kinds of DACD can be specified should be a matter for schema
administrators (ie "manually" in practice), not for access control
administrators. It really is an issue of maintaining consistent schema (in
this case for access control) so that there is a common understanding of
what each type of DACD actually means. Maintaining that commonality of
understanding of the schema is inevitably and intentionally less flexible
than the changes that other kinds of administrators and end users should be
allowed to make to the directory.

The concept of a DACD is currently less familiar to LDAP administrators, who
are often both schema and access control administrators (whether or not they
understand much about either).  The concept of a general filter is more
familiar to them, but the relative rigidity of DACDs will actually make it
easier for administrators and end users to understand in the long run, as
the point of standardizing these things is to enable full interoperability
over much larger areas than most LDAP administrators are currently
administering, with delegation within those areas.

eg "Allow printer administers to administer printers within this part of the
tree" is easily understood. If it turns out that a different set of
permissions should be granted with respect to color printers, then they are
entries with a different type of behaviour from other printers and should
have their own object class, even if they don't need extra attributes. If
they do not need recognition in the common schema applicable organization
wide as a distinct type of entry, then any variations in types of access
control should be local to the particular part of the tree that perceives
the need for this.

Authority over types of access control should not be delegated unless one is
also willing to delegate authority over schema. Delegation is rapidly moving
down to end users and lower level administrators need a clear and stable
conceptual framework.

If its really inconvenient, lower level administrators can ask schema
administrators to define a new object class. The standards do not prevent
them tagging entries with auxiliary object classes once those classes have
been defined, but only from introducing new ones without coordination. An
implementation might make such tagging unnecessarily "manual", but that it
is not a standards problem.

The goal here is to reduce variation in conceptual framework, not facilitate
it. General filters are intended to, and would succeed in, enabling easy ad
hoc changes to the conceptual framework for administering access controls.
If that was desirable, then general filters would be desirable. As it is
undesirable, they are a bad idea.

3. I suspect that the interaction between general filters, permissions and
priorities is likely to not be well understood, and result in errors when
people are given permission to change an attribute value without
understanding that this will have side effects on access controls.

4. Even with atomicity, I don't think its going to be at all easy to cope
with the interactions between ACI and replication. My error regarding
structural object classes may have resulted from wishful thinking, since it
will be even harder to cope, given that an object can move in and out of a
DACD as a result of a change in its auxiliary object classes. But at least
that only adds one kind of replicated change to worry about, on top of
changes to entry and prescriptive ACI themselves (not to mention group
membership and changes in distinguished name prefixes that can also affect
access controls). Adding potential surprises in permissions resulting from
unsynchronized replication of other attribute values would not be helpful.

In earlier discussions on the LDUP list it was recognized that this problem
of entries moving in and out of the scope of a filter made it undesirable to
allow general filters for specifying fractional replicated areas.

5. Its clear that there is a strong reluctance to introduce proper
subentries at all, despite their obvious necessity for ACI, which goes far
beyond what is immediately needed for LDUP. I would rather see a successful
quick resolution by acceptance of existing standards for subentries, or a
viable subset of them, than a protracted delay in achieving any reasonable
support for ACI at all. (The arguments raised against the current draft by
others already establish that at least some specification of the base and a
filter on object class will be necessary before final call. Adding chop
specifications does not really complicate implementation much, whereas
general filters still does to at least some extent, and would therefore
increase the resistance and consequently the delay for accepting the
necessity for having proper subentries).

BTW If the reference to manual maintenance of tagging below means that your
customers *want* the DACD applicable to an entry to change dynamically with
the ordinary contents of the entry, and you are having to change the object
classes in synchronization with other changes to the entry, then I can only
suggest seeking more sensible customers ;-)

I have assumed above that you were only referring to the manual difficulties
of tagging entries when the customer's conceptual framework changes, not
when the entries change. Implementation tools should allow administrators to
apply a general filter to re-tag entries, without a need for
standardization. A standard DUA should be able to do that just by scripting
to apply the change desired to each entry within the scope of the filter. If
standards were required for directory operations that apply to more than
entry, they would be be for more general changes, not just in relation to
access controls.

Seeya, Albert

[original below]

> applicable subentries (not just the number of actually applicable

[Steven]

[snip]

Regards,
Steven