RE: LDAP ACL model document

[Bob Blakley <blakley@us.ibm.com>]

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.

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.

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.

>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:

(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.

(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

(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.

"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.

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.

>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?)

>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.

>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.

>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.
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?

>What about storage of ACI - is that subentries or entry level or both?

Entry-level only.

>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.

>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.  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.