W3C home > Mailing lists > Public > ietf-discuss@w3.org > April 1999

RE: need review for draft-ietf-ldapext-acl-reqts-01.txt

From: Lisa Lippert (Dusseault) (Exchange) <lisal@exchange.microsoft.com>
Date: Thu, 8 Apr 1999 10:23:43 -0700
Message-ID: <FD7A762E588AD211A7BC00805FFEA54B0246D7E9@HYDRANT>
To: "'Keith Moore'" <moore@cs.utk.edu>, discuss@apps.ietf.org
I've read the LDAP ACLs requirements document, and here are my comments.


1.  Things that I like
----------------------

1.1 "More specific policies must override less specific ones".  I absolutely
agree.

1.2 Support for DENY of rights is required.  I agree this is a MUST.

1.3 Attribute-level and user-level ACLs are required.  I agree, but this
needs more definition.  Do attributes get their own ACLs?  if so, can you
specify who can set the ACLs on an attribute separately from who can set the
ACLs on the parent?  I suggest that the set of rights that can be
granted/denied on an attribute should be more limited than the set of rights
that can be granted/denied on an object.

1.4 An administrator must be able to delegate ACL management.  I agree, and
I suggest that the concept of "ownership" should be borrowed from various
existing systems.  Briefly:  the person listed in the ACL as the "owner" of
the object is the person from whom "write ACL" right cannot be removed.

1.5 "Policy resolution MUST NOT depend on the order of ACL entries"  -- This
is great; however there must be some way of resolving policy that is
reproducible across implementations that does not require order.  See 2.1

1.6 Requires support for "list entries" right separate from "read entries"
right -- This is also great, but there also needs to be a "read this item"
right that can be applied to an individual attribute.

1.7  Support for anonymous access is required -- Good

2.  Interoperability Problems
-----------------------------

2.1 Resolving multiple policies that are equally specific

The requirements draft does NOT require the ACL model to specify how to
resolve multiple policies of the same specificity. I think that should be a
requirement so that interoperability is possible. I hope this is a
reasonable requirement.  

The example situation is:   A is a member of 2 groups named in an ACL.  The
2 groups have different rights (e.g. one is granted "read", and the other is
denied "read" access)

Suggested resoultion:  There should be ONE way to determine A's privileges
in this case.  I strongly suggest that for stricter security, denies should
override grants.

2.2  Forbidding side-effects

I think this is an unreasonable constraint on systems, and could result in
interoperability problems because clients may count on no side-effects,
whereas server implementors may require side-effects.  Workflow is an area
where there can be all sorts of side-effects:  the server is aware of some
model that must be imposed on all objects that are part of the workflow
process, such that if "list" is denied on a container then "read" will be
denied on all objects in the container.

The goal is understandable and seductive:  it would be good for the system
to be predictable.  However, an access control system cannot realistically
be 100% predictable.  You can never prevent the super-user from changing the
rights of an object even when the super-user is not even listed as having
the ability to change the rights of the object.


3.  Major suggestions
----------------------

3.1  The draft suggests that naming principals which the directory
administrator cannot administer is bad. I don't understand -- why this is a
problem?   What if at my site I want to deny read access to any user
accessing my directory from *.microsoft.com?  (see 3.2).  What if the
directory in question is managed by a different administrator from a site's
user administrator? I suggest that the draft remove this restriction.

3.2  The draft discourages use of IP addresses to identify ACL principals.
Web sites do this today; it's certainly not perfect, but it's not insecure
as long as the administrator realizes what it actually does.  I would
suggest that the requirements draft remove this restriction.


4.  Minor suggestions
-------------------------

4.1  Draft says:  "ACL information MUST be an LDAP attribute" Suggested
rewording:  "ACL information MUST be ACCESSIBLE as an LDAP attribute".  In
general, the draft document tries to constrain implementations, when it
should focus on constraining the protocol to be designed.

4.2  Draft says:  "Administrators SHOULD be able to administer access to
directories and their attributes based on their sensitivity" What does
"sensitivity" mean?  It is not defined. Sensitivity should be defined, or
left out of the requirements.  I prefer to leave it out of the requirements
because I think it will be a rathole and lead to inconsistencies with other
ACL models and existing systems.  If ACL inheritance is required (which it
is), then I suggest that setting sensitivity levels is not so important.

Similarly, the draft requires support for grouping of attributes by similar
sensitivity.  Same issues.

4.3 The "all rights" right and the "all principals" principal are pretty
useful concepts in ACLs.  It's easy to grant "all rights" and then deny some
individual rights.

4.4  There should be a "write ACL" right and a "read ACL" right.

I hope these comments and suggestions are helpful.

Lisa Lippert

-----Original Message-----
From: Keith Moore [mailto:moore@cs.utk.edu]
Sent: Friday, March 26, 1999 3:19 PM
To: discuss@apps.ietf.org
Cc: moore@cs.utk.edu
Subject: need review for draft-ietf-ldapext-acl-reqts-01.txt


Folks,

The LDAPEXT working group has submitted a document called
Access Control Requirements for LDAP for IESG approval.
I'd appreciate some review of this document by the extended community.

The issue is not so much whether we should publish the document
or whether they've dotted their i's and crossed their t's.
What I want to know is, do people think that these are reasonable 
design goals for LDAP ACLs?  

The reason I'm taking this unusual step is that I'd rather have 
their design goals reviewed now, than to question them when the 
protocol specification goes to Proposed Standard.  In addition 
to this list, I've also asked IESG to recruit security and 
operational experts to review this.

Keith

p.s. yes, we should change the title to "design goals" rather than 
"requirements", and this should be published as Informational rather 
than Proposed Standard (as it was Last Called).  We will ask for 
these things to be fixed in the next revision.  But right now we're 
more concerned with the criteria in the document, and we don't want 
to ask the authors to revise the document to fix the wording  
before we submit it for additional review.
Received on Thursday, 8 April 1999 13:26:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:08:05 UTC