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

>            S2.  More specific policies must override less specific
>            ones (e.g. individual user entry in ACL SHOULD take
>            precedence over group entry) for the evaluation of an

This is one spot where these requirements disagree with the ACAP (RFC
2244) model.  The ACAP model makes no specificity distinctions.  However,
I suspect the distinction in this case is largely aesthetic so I don't
object to this.

>             S3.  Multiple policies of equal specificity SHOULD be
>             combined in some easily-understood way (e.g. union or
>             intersection).

This needs to be made more precise (I concur with Lisa Lippert's comment
2.1).  In the IMAP ACL model (RFC 2086) we tried to be very generic, but
the outcome was that it's very hard or impossible to produce a usable GUI.
Both the ACAP (RFC 2244) and AFS ACL models are very specific in this
regard.  They both use "union of positive rights - union of deny rights",
which has proved to be very usable in practice.

>            S6.  Access policy SHOULD NOT be expressed in terms of
>            attributes which are easily forged (e.g. IP addresses).

This should be changed to "If access policy is expressed in terms of
attributes which are easily forged (e.g., IP addresses) the
behavior/implications of doing that MUST be documented."  So I generally
agree with Lisa's comment 3.2.

In combination with a border packet filter, the "internal IP addresses"
concept is very useful.  When I worked at CMU, it was sufficiently
useful that we spent developer time making patches to AFS for this
facility.  (A reasonable compromise with S7 is to only allow IP address
based restrictions in a named group -- that way IP addresses don't get
directly embedded in directory object ACLs).

>             S8.  It MUST be possible to deny a subject the right to
>             invoke a directory operation.  The system SHOULD NOT
>             require a specific implementation of denial (e.g.
>             explicit denial, implicit denial).

I don't understand the second sentence.  Either deny rights are in the
model or they aren't.  If they're in the model, either they're mandatory,
or an implementation without them is permitted, but such implementations
can't support ACL replication with a system that does support deny rights.

>             S10.  The system MUST be able to support either union
>             semantics or intersection semantics for aggregate
>             subjects (not simultaneously).

This seems gratuitous.  Intersection is very non-intuitive and has little
value, IMHO.  However, if the system is allowed to support both, then an
ACL MUST have a label as to which is to be used in order to have
interoperability. 

>             S12.  ACL policy resolution MUST NOT depend on the order
>             of entries in the ACL.

I have no objection to this requirement, but I will note that one possibly
unintended side-effect is that native NT ACLs can't be used on a system
with both DENY rights and this restriction. 

>             S13.  Rights management MUST have no side effects.

Contrary to Lisa's comment 2.2, I think this is an excellent idea.  In the
IMAP ACL model we tried to allow rights to be "tied".  This just made
things too complex for client authors to do a GUI.  The ACAP model does
not allow rights to be "tied". 

>             U2.  Subjects MUST be drawn from the "natural" LDAP
>             namespace; they should be DNs.

I disagree _very_ strongly.  If at all possible ACLs should use the same
identifiers used to log into the directory (which may or may not be DNs). 
DNs are generally not suitable for presentation to humans. I'd change this
to: 

  U2.  If subjects are DNs, there MUST be a defined mapping to
  a human readable format (e.g., user@realm).  If subjects are not DNs,
  there MUST be a defined mapping to DNs.

>             U5.  Administrators SHOULD be able to administer access
>             to directories and their attributes based on their
>             sensitivity, without having to understand the semantics
>             of individual schema elements and their attributes (see

I don't know what this means.  I concur with Lisa's comment 4.2.

I'd also mention that the white pages application, a primary application
for directories, has a very interesting requirement which I didn't see
listed:

 * It MUST be possible to allow a user to modify some attributes of their
 own white pages entry, while retaining administrative control over other
 attributes.  It SHOULD be possible to express this in an ACL which
 applies to all entries within a subtree.



In general, the spec seems fairly good and is quite closely aligned with
what ACAP did.  I particularly like the goals of usability and simplicity
as this will hopefully prevent ludicrous models like the Posix ACL model.

		- Chris

Received on Wednesday, 14 April 1999 20:37:36 UTC