Comments on the LDAP access control list model. 00.txt

[Alan Lloyd <Alan.Lloyd@OpenDirectory.com.au>]

Dear all - my previous notes on this draft were somewhat blunt- however,
I did perceive that that some adoption of the proven and scaleable X.500
ACI model would be applied.
So I really do not understand the motives are with this stuff, except to
say that it is different, and IMHO has many holes, wont scale to well
and will leave implementors guessing. The  perceived result from using
this draft is that LDAP server systems will possibly have "back doors"
ie the AC could be suspect.

Ed Reed provided good comments so I will try not to replicate them here.
Detailed comments.


1. - 2.2 bullet 2.

Entry level stored ACI dictates a very process and configuration
intensive system. In X.500 prescriptive ACI is used to govern single
entries or 10,00000000s of entries. If one had to configure each entry
and that took a minute - then on a 250k entry system - it would take a
man year to configure. We can configure ACI for a 10,000,000 entry
system in half an hour with our X.500/LDAP engine.

In addition, entry level stored and configured ACI will be frought with
human error so that configuration mistakes can cause back doors and
render the ACI useless.

It is not said in the document re ACI and alias entries. Say under the
US we have A and B entries. B is protected so that all entries below it
can not be seen by some users.
Say an outside user is given access to part A of the DIT and gets to
create alias under A to target B entries. Are the items under B now
exposed?  Implementations have to watch this.

In distributed X.500 we verify Acess control on entry to the system
(domain checking) so that repeated attacks for targest that are
protected are stopped at source. ie they dont use system resources to
get to the entry to find out that they cannot read it. see X.500
Prescriptive - domain based ACI - it is more effective - than entry
level.

However, this means that LDAP servers will have to adopt X.500
subentry,ACI area concepts and its ACI model.

Entry level ACI will cost in performance - 




2. - 3.2 General - Subject Security Attributes.

These use a few DNs to specify  Defining and Assertive Authority and
Types.

It is not described in the text what verification is made with these
values (Ed raised an issue here) ie. do these DN objects need to exist
in this server or a referred server. Who is  responsible for the
Type/Value presented from the user. If there is no server processing re
Trust defined for these DNs - then the are redundant - just any old DN
will do.... As for proving roles , etc - this needs to be defined...

I believe that every item defined in an ACI model MUST be defined in
terms of process and relationship - otherwise its open to mis use or
back doors. The current definition for these is untrusted and ill
defined.


3. - 3.2 General - Subject Security Attributes. Trust and MLS
I think its very dangerous to state Clearances here. eg Secret. Formal
defined Clearances are used in the intelligence and security agencies
and it would imply that LDAP servers can be Multi Level Secure systems
based on: some unsigned strings attached to entries with values (DNs) in
them that may or may not point to other valid (bound by cryptography)
entries.

There is a leap of faith here to say the least.


4. Classes of Attributes
One cannot protect information unless the protection definition is
bullet proof.
This is the biggest hole in the  document.

Are these classes universal with defined sets of attributes or do they
relate to object class types. Do we have a"critical" for Organisational
entries and a critical for "device entries which is different. Do
different servers interpret these according to local configuration and
that something that is "sensitive " in one server - is not so sensitive
in another that has in part replicated that data?

In addition, the LDAP attribute model has really messed up with
"attribute thing: lang-US; value $home.

So how is ACI appled to the options and labels of LDAP attributes- is
the English home phone number critical in one environment and normal in
another.
ie. ACI in LDAP land has to be type/value based on specific attribute
types and consistent with the domain of interest. Mind you this hill be
a major performance hit on big systems. (substring searches in ACI
processing)?

This text needs to be re written to deal with protected attribute types
and values - otherwise  trust is in the system is lost.


5. 4.1.4  Access permissions

Not sure what  Manage and Use are - please explain "priviledged
operation" and "sensitive data" - what are these in terms of process and
trust and definition.



6. -6.1 - Request/Respnse control

The response seems to come back in the control field . The same codes
are also possible in the LDAP result. Which one is preferred. ?


7. 6.3 
The text takes a bit of reading - several times and it is still not
clear re "removes any subject sec attrs"  Can one rewrite this and
distinguish between the subjects entry which has the possible
credentials -  and the credentials presented in the LDAP operations and
how both of these are assessed.

Is anyone concerned re the User continually applying a test credential
in a bound connection to probe and attack the system - ? It seems that
this is possible. see bullet 2.


 8. Extended Ops 

Not sure how these things are derived - In X.500 a requestor DN can be
used in in every request and this could be assessed with target entry
permission. Does this extension imply that the server will believe who
made the request (even if its being masqueraded) and let someone
somewhere know ACI information?

Some text is needed here re how these operations are protected and
authenticated.


Not sure how the SearchAttrs and Arttvals get here. given that they are
filter and EIS issues. Please explain.


Rights list: Which object - understand the words Parent and Self .  Not
to sure re New Parent or what these bits do. Please explain.

Attribute Class: see notes above - but if provided to a User how do
Users  make sense of it re attr types and values if the context of
classes is local and non uniform. Please explain.


9. General 
No authentication or precedence levels are defined, therefore nested ACI
and what users use under different authentication ideals is wide open to
mis use. Mutual Authentication and its relationship with the population
of ACI needs to be described. Please explain.


In closing - there are many trust and operational issue with the
document as it stands. Its a great pity that X.500 access controls are
not embraced. However, as we link X.500 core systems to LDAP servers,
then the X.500 ACI can dominate LDAP servers and therefore LDAP server
ACI models  will not be required. 

It is important though that trust and security are paramount in
directory systems and that if X.500 has a far superior ACI scheme which
is proven to work in a distributed and a domain based environment then
that will be a major, major competitive edge (and marketed that way) for
X.500 systems.  With LDAP interfaces in X.500, that means that they can
be deployed as  either well protected LDAP servers or X.500/LDAP core
distributed directory systems.


regards alan





Are these classes of attributes relate to the