RE: LDAP ACL model document

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

Thanks for the considered reply Bob.

It seems that the single server- local policy theme predicates the ACL
design proposed.
This is really useful ?
If it is just a singler server non distributed mode of operation then
why have a standard at all. If the ACL proposed  it is so open to
interpretation, implementation methods, evaluation methods, trust and
accreditation - why bother at all.



> -----Original Message-----
> From:	Bob Blakley [SMTP:blakley@us.ibm.com]
> Sent:	Tuesday, April 07, 1998 3:47 AM
> To:	Alan.Lloyd@OpenDirectory.com.au
> Cc:	internet-drafts@ietf.org; ietf-ldapext@netscape.com
> Subject:	RE: LDAP ACL model document
> 
> Alan Lloyd writes:
> 
> >The following comments are provided:
> 
> Thanks for taking a look at the proposal and taking the time to
> comment.
> 
> >a) Why on earth are we proposing something so different to X.500 ACI.
> >When that works......
> >
> >Can any one on this list give me one good reason with some sound non
> >religious statements (not its too hard, etc)
> why!......................
> 
> I'll address this in the specific comments below
> 
> >THE WORLD IS TRYING TO STANDARDISE ON SECURITY RELATED PROCESSES FOR
> >GLOBAL ELECTRONIC COMMERCE AND DISTRIBUTED PROTECTED DIRECTORY
> SERVICES
> >WHICH INCLUDES AUTHENTICATION AND ACCESS CONTROL MECHANISMS - HAVE WE
> >OVERLOOKED THIS POINT......
> 
> This is a little general, and I don't know exactly what would
> constitute
> a satisfying response, so I think I'll leave it to the working group
> audience
> to answer the question in their own minds.
> 
> >THE TEXT BELOW
> >
> >Eg.
> > Subject security attribute information is
> > associated with subjects.  Each subject must have
> > an LDAP directory entry, and a subject's security
> > attribute information is stored as attributes of
> > its directory entry.
> >
> >HOW DOES THIS WORK IN A DISTRIBUTED LDAP SERVER ENVIRONMENT - WITH
> >REFERRALS TO  OTHER SERVERS WHICH DO NOT HAVE MY SECURITY REFERENCES
> IN
> >!!!!!!
> >
> >X.500 does this with mutual authentication - in a distributed trust
> >model. And that works.
> 
> Our LDAP ACL proposal also assumes an underlying authentication
> mechanism
> which provides (at least) the authenticated DN ("access id") of the
> requesting
> subject principal to the server at bind time.  In the case of a
> referral, it is
> assumed that the LDAP client will bind to each server it is referred
> to, and
> will authenticate its subject DN on each bind.  In this way, each
> server knows
> at least one security attribute of the client.  It's not clear what
> significance
> mutual authentication has in this context; certainly authenticated
> server
> identity is important to clients in some contexts, but it's not
> related to
> how the server checks authorization of authenticated clients to its
> resources.
> 
	In the case of simple authentication  how does the referred
server know the DN of the User??  In the distributed X.500 world mutual
authentication is performed BETWEEN  cooperating DSAs.
	Iie. Your assumption above is the thing that is wrong so that
wont work

> Specifically, though, our proposal assumes that the authentication
> mechanisms
> defined as part of the LDAP standards suite will be used, and will
> provide
> to the server an authenticated DN.
> 
	But how does every LDAP server on this planet get all the Users
Dn's on this planet . ie. The LDAP only server model without
distribution is broken...


> Your questions about distributed trust model issues and servers which
> lack
> security references to the requesting client are addressed below.
> 
> >This draft ....DISTRIBUTION, Mutual Authentication, Commercial
> >Usefulness and practicality ?????
> 
> I'm not sure I understand in detail what you're trying to ask here.
> "DISTRIBUTION" for example -- do you mean "(how) does the model work
> in
> distributed
> server environments?", or "how is aci distributed among servers", or
> something else?  I'd appreciate clarification of the questions here so
> that I can give a coherent answer.
> 
	Clarifying both aspects would be useful


> >WHAT SEEMS TO BE TOTALLY MISSING IS THE aci FRAMEWORK BASED ON THE
> >DISTRIBUTED INFORMATION MODEL AS USED BY DIRECTORY SERVICES . aci
> MUST
> >BE ENFORCEABLE ACROSS MANY "SERVERS" WITH COMMON PROFILES with THE
> USE
> >OF STANDARDS. Not be open to local variations cause by the semantic
> and
> >trust interpretations of locally defined strings.
> >
> >COMMENTS - 3.2 defining authority
> >having strings represent levels of clearances as a semantic without
> any
> >tie to a distributed trust model is a waste of time. eg a US "secret"
> >string could be interpreted as being dominated by a UK "unclassified"
> >string - who sets the rules here - a local issue???
> 
> Precisely so: the rules are local, because servers are assumed to
> enforce
> the policies they have defined.  Our experience with both distributed
> directory services and internet applications has convinced us that
> there
> is no way to define a single set of privilege attributes whose
> semantics
> can be agreed to by all the organizations which want to deploy servers
> on the Internet.  Given this, we need LDAP servers to be able to
> support
> management of user attribute information on the deploying
> organization's
> terms.  At the same time, we don't want every organization to have to
> create a directory entry for every user of the Internet.  The only way
> we can see to satisfy both these objectives is:
> 
	X.500 ACI permits this AND it also permits domain based
Authentication and ACI to be applied across many DSAs .. so why not use
the same spec...
	X.500 DSAs support LDAP - but now they have to support two
regimes of ACI - The working option and this one.

	If there are any Users on this list - never mind - its just more
work for you and there will be holes in this ACI messup no doubt...

> (1) Allow the client to transmit a view of the user's credentials,
> containing
> AT LEAST a DN authenticated by some authentication service whose
> assurances
> are likely to be broadly accepted (e.g. an X.509 certificate, issued
> by a
> commercial
> CA, with the subject's DN in the name field) as well as OPTIONALLY
> some other
> privilege attributes asserted by some identifiable organization (e.g.
> group memberships, role names, etc..., tagged (via the "asserting
> authority"
> field) with the name of the organization which thinks the subject is
> entitled
> to these attributes.
	So now each LDAP server in the world must be configured with
dedicated paths to all its supporting CAs - as opposed to being
connected by a distributed directory cloud. Scale
	What does the client do when it receives a cert in a mail
message that the server does not know which server the issuer DN is
in???

	One can do all the above X.500 with its ACI....


> (2) Allow the server to look at the "other privilege attributes" and
> determine
> whether it is willing to accept them, based on its trust relationship
> with
> the "asserting authority", and
> 
	One can do this with X.500 with its ACI....

> (3) Allow the server to represent its own organization's view of the
> subject's
> privilege attributes, either by an algorithmic mapping of subject
> identities
> and their asserting authorities to the server's privilege attribute
> space, or
> by looking up the subject's privilege attributes, based on the
> subject's
> authenticated DN, in its own LDAP repository or in that of another
> server which
> it trusts as a source of privilege attribute information.
> 
	One can do this with X.500 with its ACI....

> "Net net" - our view is that there CANNOT be a unified view of "secret
> clearance" among the US government
> and the UK government, and neither can be presumed to dominate the
> other -- but
> it WILL sometimes be
> necessary for the US government to grant UK government cleared
> personnel access
> to classified information.
> Thus it will be necessary to allow the US government server to define
> a policy
> which explicitly relates UK
> government-assigned privilege attributes to US government information
> classifications.  This is why the
> "asserting authority" field is included in the privilege attribute
> structure.
> 
	I think you missed the issue here - what trust is there in a
string or numeric value if these are not bound to the technology that
processes them via some means of cryptographically bound information. eg
what says that CEO is less than VP or greater. Why develop weak trust
models in a local server for local clients that cannot be applied for
clients that come in remotely to use your data for business purposes.
Remote clients in this context are the ones that you dont know the DNs
of - who want to do business with you... via YOUR directory..

	Local information in a local server protected with arbitary
trust using arbitary strings is not what I call directory services - its
a local pile of bits.

	Distributed directory services with domain based and consistent
auth/aci mechanisms provide the utility to the many.




> We don't see how situations like this can be handled if the access
> control
> model builds in an assumption that
> a single policy, defined in the standard, must be in force across
> servers which
> belong to different organizations
> which in the real world don't agree on policy.
> 
	X.500 does not do this - it provides mechanisms that can be
configured to protect 1 entry to 100,000,000s of entries with one or
more policies and these can be applied across 1 - 10000s of servers. 

	AND IT WORKS

	This LDAP ACI approach is bespoke and limited and different - I
keep asking why - and it seems to be that X.500 has yet again been mis
interpreted (eg LDAP is now twice the size of DAP with half the
functionality - because of mis interpretation).




> >Ditto with all the other text eg semantics of roles - is there a
> >standard for role trustworthyness conventions? - ie the security
> >attribute stuff is untrustworthy, unworkable and unscaleable.....
> 
> I think my explanation above is relevant to the first part of this
> statement.  However in order to give a complete response I think I
> need more information about why you think this model is untrustworthy
> (e.g. what is being trusted, and by whom, which should not be trusted
> or is likely to fail?), unworkable (what is it you think won't work?)
> and unscaleable (what data do you think grows too rapidly to be
> accomodated
> by the LDAP servers which will be storing it?  At what number of
> subjects, directory entries, and resources do you think the system
> overhead becomes too great?  What do you think the growth function
> is?)
> 
> 
	As said above - a single client server model with customised ACI
is fine  and who cares about ACI in this context. However if one wants
to connect up LDAP servers with X.500 DSAs and place these as the
international directory infrastucture for major corporations,
telecommunications carriers, etc then consistent trust models, ACI
mechanisms and domain based integrity is required. Because the LDAP work
does not even consider distribution - just a complex client having a
"bash" at any server it can find - then these issues dont arise.
	That just means that the requirement to buy an LDAP server is
questionable when it just wont fit in with the requirement to work into
a global directory model

	The good thing about all this all the deficiencies in LDAP are
now being recognised in a wider context - and its better to buy a X.500
DSA as an LDAP server - because it scales - than buy a single LDAP
server that wont connect to anything accept local clients.

> >3.4.1 Credential versions - how is this enforceable - how does one
> >migrate versions - what are these ?? Are there trust differentiators
> >with versions ??
> 
> I don't really think this is an issue now; we've included the version
> number so that if it becomes necessary at some future time to change
> the credential format, the new servers will be able to recognize "old"
> credentials, and vice versa.  Minimally if the change is semantically
> meaningful, policy could be defined at that time to reject credentials
> of the wrong version, but since this is version 1, and no other
> numbers
> are being proposed, it seems hypothetical to argue.  If the group
> feels
> the version number should be omitted, that could be done, but it would
> then not be possible for a server built to the resulting spec. to
> recognize
> that it had received a "new version" credential if such a thing ever
> comes to exist.
> 
	Have you seen the credentials already defined in X.500 ?


> >4.1.2 ACL Owner attributes - not sure why we have these when the
> X.500
> >model requires that a  User has Permissions - and no semantics are
> >applied re admin - they are just users with many privileges. This is
> >wasted definition and thus wasted user configuration effort.
> 
> ACL owners were introduced to deal with a subtlety in access control
> semantics:
> if "change aci" is a permission in the access control list itself,
> giving a
> user that permission also gives the user the ability to propagate that
> permission
> to other users, unless very complicated additional mechanisms are
> added, or
> unless a very rigid rule (e.g. "only the directory root admin can
> grant
> or deny the "change aci" permission) is a adopted.  Both of these
> solutions are
> problematic in some environments.  The problem is solved by separating
> the
> policy governing who
> can administer aci from the policy governing who can modify other
> attributes of
> the entry.  ACL owners
> are the mechanism we use to accomplish this separation.
> 
	This does not matter in a single server environment - so why
bother.



> >4.1.3 Attribute Classes
> >Attributes are grouped in classes... this is also unscaleable,
> >unworkable, cannot be uniformally applied - different servers will do
> >this differently no doubt....
> 
> Again I'll refer you to the text above for the discussion of uniform
> application across servers with different views of policy.
> "Unworkable"
> I don't know how to interpret again, as I'm not sure what's being
> asserted.
> However I will note that our implementation of LDAP is currently
> shipping
> with this feature; it was not hard to implement and the user interface
> for
> administering aci in the context of attribute classes is simple and
> understandable.
> 
	OK for a single server - so go for it. 

> Your scaleability critique here comes as a surprise, as the grouping
> of
> attributes was introduced precisely to solve scale problems associated
> with
> managing aci on a per-attribute granularity.  There are two potential
> problems
> this causes: the first is the amount of storage required to handle
> per-attribute
> aci (as compared for example to per-entry aci); the second is the
> number of
> attribute types the administrator must be aware of when managing
> policy
> on a per-attribute basis.  Our experience and analysis indicates that
> both
> of these scale better in an attribute-group model than in a
> per-attribute
> model.  Perhaps you could clarify what data you think grows too
> rapidly
> and what you think the growth function is?
> 
	Attribute specifications in prescriptive ACI is not a problem -
we deal with 1000,000s of entries so entry level peculiarities are
really for the small single servers 1000 entries.
	Storage well most DSAs will have an attribute type range of
about 100 attributes  and OIDs are about 8 bytes so 1k per entry on
100,000 is 100mb but if applied through presriptive ACI as per X.500
then this could be as much as 5 mb OF DISK.

	May I ask is your ACI model is founded on entry level stored ACI
in a small LDAP memory based/cached server? And therefore all the above
re attribute grouping and storage restrictions applied?


> >What about storage of ACI - is that subentries or entry level or
> both?
> 
> Entry-level only.
> 
	No good for large directory systems -- 
	So what do we do now - the ACI model presented does not work
because of assumed knowledge of DNs by all single LDAP servers which is
not there , the trust model re string privilege is local and open
arbitary processing - and has issues with non local users, the attribute
grouping is predicated on entry level storage requirements in a small
LDAP server and the thing is operationallly unusable in large
distributed directory systems


> >IF I AM BLUNT then its about time some one said that enough is
> enough.
> >This LDAP effort is not standards setting - it is causing a global
> >information mess.
> 
> I'm afraid this is an issue for a wider forum, which I'm not the right
> person to address.
> 
	May I suggest that in the interests of directory service
delivery across this planet in the most optimal way that the X.500 ACI
model is reviewed and the text redrafted - I am sure it will work - and
if it does not lets modify it - I am sure there are many that do not
want two incompatable ACI regimes.

> >Access Control and trust in distributed directory systems is
> fundamental
> >- and we have a standard..
> 
> I agree entirely on the first clause; as far as the second is
> concerned,
> there certainly is *a* standard.  However there is no LDAP standard,
> and our assessment is that the X.500 standard has properties which are
> not appropriate for use in an LDAP environment. 
> 
	It was also said that DAP had too many overheads hence LDAP  -
but it is now proved that DAP smaller and has more features than LDAP - 
	Some views can be very wrong - cant they....

	Please define these properties that not appropriate - As they do
not seem to be identified in the comments above..

	Can the list be circulated and aired - I would hate to think we
make a mess of this ACI issue because  mis interpretation or something
else.
	I do not understand why this has not been circulated because it
would be really useful for the X.500 developers to know what does not
fit the LDAP world when the LDAP world is based on X.500?


>  On the basis of discussions
> at the LA meeting, we've taken an action item to discuss in detail the
> justification for departing from X.500 syntax and semantics, and we'll
> post
> the results to the list as soon as we've completed that action.
> 
> >Whats the process for violent objection based on the fact that a good
> >working international standard already exists. And the one proposed
> is
> >unworkable....
> 
> Well, this certainly looks like a violent objection, and of course the
> IETF process in general is that drafts are proposed and comments are
> made
> on those drafts.  In that sense you have just exercised the process.
> 
> >Hopefully most will just ignore the text and let it die.
> 
> Perhaps, but I think the issues are too important to ignore, and at
> some level
> it seems to me that you agree.
> 
> regards alan