Subject: RE: LDAP subentry alignment with X.500 subentry

From: "Lloyd, Alan" <[email-masked]>
Date: Mon, 10 Jul 2000 20:08:01 +1000

No worries - but the real issue to me is an administrative plane in a
directory for schema, collectives, security, aci, etc means that these
entries can be partitioned into their own regime - in that there is
administrative security applied to these entries and they get named
seperately from the "user entry plane"..ie does the ACI on ORG x get its ACI
properties from a management plane of named entries (which have their own
ACI regime - distinct from the user ACI regime ) or are they coupled because
it all exists as one compound entry.

There are five aspects to ACI..that is coupled to the User authentication
process.. these are 
The Operation
The Name Space
The Object Class of the entry
The attribute type/value within OC/entry 
and the Time the operation is allowed.

Given that very strong ACI code (in terms of vetting) can be applied to the
directory operation and name space of the entry and its OC. Having named
subentries for management is a much more trustworthy approach than compound
OCs that exist under a User "named" DIT. In addition if entries are renamed
becuase of business, service and user changes, it may means the ACI
management model has to be recalculated re its security. Whereas the named
entry for management - admin model is still the ACI and schema reference
point in the directory.

Naturally this discussion can be lengthy - but one area that one looks at in
military security - is "seperation of duty" - and how operations that change
one thing affect others.. An explicit "named" management and security
information model  with its own privileges and ACI - to me is much better
than a compound one - that can be accidentally affected by such things a
user information name changes..

I hope this "helps"..

regards alan

-----Original Message-----
From: Rob Byrne - Sun Microsystems [mailto:[email-masked]]
Sent: Monday, July 10, 2000 7:50 PM
To: Lloyd, Alan
Cc: [email-masked]; 'Mark C Smith'; 'Kurt D. Zeilenga';
[email-masked]; [email-masked]; 'Ed Reed'
Subject: Re: LDAP subentry alignment with X.500 subentry

Hi Alan,

Thanks for that...but I think I was not precise enough in my question.

The current proposal for ldapACI does put them in entries but they come with
a
built in scope rule, which can be "subtree".  So, I suppose my question is
rather, "apart from leveraging the scoping rule of subentries what is the
big
plus we get from putting acis into subentries ?".

Thanks,
Rob.

"Lloyd, Alan" wrote:

> The reason for ACI in subentries is that one can support the nested
> directory admin model and make domain based ACI decisions over distributed
> (X.500) DSAs. Whereas entry level ACI - may let a user do operations on
the
> directory using the directory resources only to find they are denied to do
> these at the entry level (and on millions of other entries.. ie entry
level
> ACI is easy to implement - but a rally bad way of working in terms of
system
> level resource protection, large scale protected distributed systems - and
> operationally hard to configure and manage..
>
> ie. configuring entry level ACI for millions of entries - across many
> servers - at the entry level takes time ... This process is also open to
> having errors introduced where back door holes might be the result of
> misconfiguration.
>
> If one adopts admin points and rules based configuration and deals with
> large scale distributed directory entries - then the nested admin model is
> best - simply becuase it does scale and is easier to operate with rules -
> This approach also align with conventional management models used by
> business ie top down. If an entry level aci is used - one must consider
the
> cost to configure and test, the use of directory resource before making
the
> actual ACI decision, the hierarchy of entries, their denials and
permissions
> and any alias derefencing...
>
> as an example - say one has a distributed directory with 250 million
entries
> in it and one wanted to apply a new rule for a new set of users and
business
> services - for each entry... if an entry takes even half a minute to
> configure.. the job will be a life time career...
>
> regards alan
>
> Stephen,
>
> snip
>
> 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.
>
> snip

---

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 11 Jul 2000 11:13:42 +1000

Rob,

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.

The problem with scope in entry ACI is that, when searching below a scoped
entry, how do you determine the applicable ACI. Read all superior entries?

Since you asked for pros and cons, another aspect of entry ACI that is
suboptimal is the cost of applying it. Everyone seems to assume it is free
and yet it has a significant impact on server performance (no figures,
sorry). For example, suppose subtree A contains 10000 entries, 9000 of which
are in subtree B under A. Suppose user X is not authorised to access B.
Because of entry ACI, a search by X of the subtree A will result in all
10000 entries being read for their ACI, whereas the use of prescriptive
(subentry) ACI will mean that at most 1000 entries will be accessed.

Ron.

-----Original Message-----
From: Rob Byrne - Sun Microsystems [mailto:[email-masked]]
Sent: Monday, 10 July 2000 19:50
To: Lloyd, Alan
Cc: [email-masked]; 'Mark C Smith'; 'Kurt D. Zeilenga';

Hi Alan,

Thanks,
Rob.

the
level
system
the
the
permissions
entries
business

---

From: "Lloyd, Alan" <[email-masked]>
Date: Tue, 11 Jul 2000 15:56:26 +1000

In addition to Ron's input - which is always spot on .. 

With this issue one has to step back and look at the major issue with LDAP
servers and their lack of distribution - that X.500 already has. When
machines do diffrent things, (eg LDAP servers vs distributed X.500), their
management and control architecture will also be different. Certainly when
one gets into distributed system management, knowledge engineering and
security systems - the management will be very different to that of a single
client-server system . 

As per my last mail re separation of duty - and dedicated control planes (as
per X.500 DSE types, admin and subentry named - ACIand schema objects/object
classes, etc) - If one has a clear management and control  model of
distributed directory space - that deals with schema management,
Authentication levels - tied to ACI regimes, Collective Attributes, Contexts
(time/language), Labels (MLS military security), etc (as per X.500).. then
one can engineer these control planes as distributed, nested administration
points - and write the processing for these as quite distinct processes from
the code that services the normal user access to directory entries - which
of course must be policed by the control regimes. 

Whereas with no control plane agenda or model - and the use of compound
entries, this could lead to all sorts of operational weaknesses (as Ron
describes) and the possible inclusion of weak fragile security and
management code.

When a user binds to a directory with none, simple, strong authentication
that the ACI processing is latched to. Ho do you vet the processing is clean
and trusted comensurate to the authentication  level demanded if it is
scattered through out the User plane processing. In addition - and probably
this is the main distinction between LDAP servers and distributed X.500 with
its distinct Admin area management system - is that these dedicated
management objects for ACI/schema control, etc, can be (and must
be)propagated to subordinate directory systems more cleanly than filtering
partial replicas of user entries - which can be under all sorts of dynamics.
This obviously means that the hierarchy of management control and its
security is effected across the distributed system in a much more trusted
(separated) way.

With the Search issues like Ron describes - as well as embedded attributes
for management control in normal entries - how would one enforce such a
random control process - eg upwards, sidewards and downwards? and dont
forget alias issues ! 

With the X.500 admin point and dedicated ACI and schema type objects the
governance its always downwards - and "always" means it can be built in
trust worthy way. It can be designed to be "predictive" and any resulting
pre processing of ACI when ACI or schema control is changed, can be
propagated across a distributed system - consistently and effectively..

My issue with - and always has been with non distributed LDAP servers -
where one must replicate everything to everywhere - and there is no
distribution and no distributed coherent control plane management model -
does mean that any operational security is bound to be weak and fragile.. 

When one sees a distrubuted directory service to underpin a global
organisation's business infrastructure with PKI, OCSP, DEN, DNS, User
authentication regimes, white, blue, green, yellow pages services,
catalogues - 10s - 100s of millions of role based users - and the need to
support a predictable, high capacity, distributed authentication/ACI model
(to protect the directory service), the X.500 Admin model and subentry ACI
with profiled rules - wins out. 

And when you apply this fundamental processing things to a system do slow
down a little compared to those servers that dont apply ACI or are just a
single server. And its a pitty that ACI and information integrity testing
does not get incuded in some directory test reports we see..

There is a danger in discussing ACI models that by saying X.500 does this
and LDAP servers do that.. that the LDAP server ACI approach will firmly
concrete the role of an LDAP server to be nothing more that a single non
scaleable single ACI regime system. The basics of X.500's nested admin
points, DSEs, knowledge and control planes - is that it works for a single
DSA or as a distributed system - in a way that it can be built - and
trusted.

In discussing this re an ACI attribute or an Admin/Subentry ACI, etc - one
must look at the system model and its distribution requirements and the
ability to do predictable govenance. 

regards alan

-----Original Message-----
From: Ramsay, Ron 
Sent: Tuesday, July 11, 2000 11:14 AM
To: Rob Byrne - Sun Microsystems
Cc: [email-masked]
Subject: RE: LDAP subentry alignment with X.500 subentry

Rob,

Ron.

-----Original Message-----
From: Rob Byrne - Sun Microsystems [mailto:[email-masked]]
Sent: Monday, 10 July 2000 19:50
To: Lloyd, Alan
Cc: [email-masked]; 'Mark C Smith'; 'Kurt D. Zeilenga';

Hi Alan,

Thanks,
Rob.

the
level
system
the
the
permissions
entries
business

---

From: "Ed Reed" <[email-masked]>
Date: Thu, 13 Jul 2000 09:43:59 -0600

Kurt - I disagree with your proposal to replace LDAPsubentry with
X.500 subentry, mainly for reasons already expressed on the list:

1) the subtree specifier is omitted because:

   a) it introduces what seems to be a lot of complexity to determining
       which entries a subentry would refer to, 
   b) it introduces what seems to be a lot of complexity to determining
       which subentries apply to a particular entry,
   c) it introduces what seems to be a lot of complex thinking for
       administrators who want to understand how to tell their system
       to do something, and to understand what their system is trying
       to do
   d) the author (me) has not been exposed to many (any) real-world
       problems solved by the subtree specifier which are not or can
       not be as well handled in some other fashion.

2) As Steven Legg pointed out, X.500 vendors who wish to use the
same mechanism to implement subentry and LDAPsubentry may treat
LDAPsubentry as a limited subset (for the most part, see below) of
the X.500 subentry, with an implicit subtree specification.  The
one place I'm aware of that the LDAP subentry is not a proper
subset of the X.500 subentry is that the LDAPsubentry MAY be
nested, whereas the X.500 subentry may not - but that's really
just a structure rule variation, isn't it?

Of those reasons, the first three of 1 are the qualitative reasons.  As for the
fourth - informal conversations I've had with vendors who HAVE implemented
the subentry suggest that it IS complex to implement, it IS hard to
use correctly in operational environments (because of a, b, and c) and
it's NOT widely used.

I've no objection to extending LDAPsubentry at somepoint in the future
to have full X.500 semantic subentry behavior - but I'd rather let those
of you who think it's worth while do the expansion and let the market
place of real-world operations provide the compelling reason the make
that the standard, rather than try to force it on lots of folks who don't
see the need, today.  Or put another way, I have no problem watching
LDAPsubentry attrophy from lack of use if the X.500 subentry is over=
whelmingly adopted by the LDAP community at large.

Ed

=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Kurt D. Zeilenga" <[email-masked]> 07/03/00 10:25AM >>>
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: "Ramsay, Ron" <[email-masked]>
Date: Fri, 14 Jul 2000 14:59:32 +1000

Rob,
 
I wasn't try to say that filters are not unpredictable, or that the scheme
you propose is unworkable.
 
My point is simply that, if Joe Average, Sytem Administrator, defines a
filter (eq employees with manager X cannot access payroll files) and if
user's actually have access to that attribute, there may be security
implications (eg user deletes manager attribute). Note that filters have
syntax (easy), semantics (harder) and exception (very hard). One exception
is the tri-valued nature of the filter ('unknown').
 
Ron.

-----Original Message-----
From: Rob Byrne - Sun Microsystems [mailto:[email-masked]]
Sent: Friday, 14 July 2000 2:08
To: Lloyd, Alan; Ramsay, Ron; [email-masked];
[email-masked]
Subject: Re: LDAP subentry alignment with X.500 subentry

Ron/Alan/Albert, 

Thanks for your responses. 

 <snip>  

[Ron] 

  in entry ACI.

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. 

 <snip>