Re: draft-stokes-ldapext-acl-reqts-00.txt

[Mark Wahl <M.Wahl@critical-angle.com>]

> These words were pulled directly from RFC 2119 to aid the reader and avoid
> the reader from having to go pull the RFC to get the definitions. I 
> understand the desire to do this, but I keep wondering if you would never 
> have submitted this comments if I had used the standard words that RFC 2119 
> suggests for inserting a pointer to RFC 2119 (The replication requirements 
> document just pointed to the RFC).  No where in RFC 2119 does it imply that 
> that RFC is for protocol only.  I suggest I go back and just point to
> RFC 2119 and remove the definitions in this section.

I am concerned with the reference to RFC 2119 from a requirements document 
because of the way RFC 2119 defines the term "MAY".  It allows a vendor to not 
include this item in their _implementation_.  I would be happy though with 
replacing this text to a reference to 2119 so long as the words "MAY" and 
"OPTIONAL" don't occur in this requirements document.  With the possible 
exception of nested groups, they don't now.

> What is meant by explicit denial here is the support of a "rights bit" whose
> interpretation is "deny operation x" as opposed to "grant operation x".

This is OK so long as the rights combination process is not additive, e.g. 
a user doesn't get the rights of all user classes which he might fall into, 
only the most specific user class.  

While re-reading this section of the document, I was concerned about the 
requirements S9 through S11.  These requirements mean that a directory 
deployment would be required to have two large "switches":
 - default is ( grant | deny )
 - aggregates are ( union | intersection )

I am not aware of any access control system used in directories today which has 
these switches: these choices tend to be made in the specification, not left
up to run-time.  X.500 Basic and Simplified access control, for example, don't
allow the user to change to "default grant" semantics. Flipping either of these 
switches on an operational directory would have serious consequences and would 
probably invalidate existing access control definitions.  I would like to ask 
the list whether these large-grain controls are necessary for deployment.  If 
they are not, then I would prefer to have these requirements eased to: 
 S9. The specification SHOULD be based on one of the following semantics: 
     default-grant or default-deny.
 S10. The specification SHOULD be based on one of the following semantics
     for aggregate objects: union or intersection.

> Granting a privilege attribute to one subject MUST NOT implicitly grant a
> different privilege attribute to the same or any other subject.

OK. This is an area where a user needs to be protected by their 
management tools from making the wrong decision.   In one deployment they
changed from the policy 
 everyone: read
to
 everyone: read
 user "Manager": write
As a result, the Manager lost read permission.

>>An Administrator MUST be able to create new partitions at any point in the >>directory tree, and MUST be able to merge a subordinate and subordinate 
>>partition.

> Next, I can accept this requirement if stated as 'SHOULD'.  The reason for
> SHOULD is the administrator needs to have authority (1) over the given point
> in the tree to create a new partition, and (2) over both the superior and
> subordinate partitions to do the merge.

Technically I think it needs to be MUST as this authority issue is an aspect of 
the deployment of the access control specification, not the specification 
itself.  The specification will have ways of determining who is administrator 
and who can  partitions, but the specification "MUST" allow Administrators to 
create and merge partitions.  If a specification does not allow merges, then 
the reason would be that specification left out the section on merging.  

Even with a MUST requirement, the specification can still say "If the 
createPartition right is granted to the user, then the user can create a 
partition.", and the deployer can choose not to set the createPartition bit
for a user.

Still, I would be happy with the requirements document if it contained 
exclusively SHOULD and SHOULD NOT statements.  A MUST/MUST NOT requirement 
won't stop anyone from writing a specification and publishing it as 
Informational or Experimental.  

>>An authenticated user or administrator MUST be able to determine the type of 
>>access control specification which applies to a particular partition by 
>>performing a search operation. 

> Can you please elaborate on '...determine the type of access control 
> specification...'?  Are you referring to an access control policy definition
> language?

No, something very simple.  Require each specification to have a unique OID.
Require these OIDs to be found in well-known places, such as a 
supportedAccessControlMechanisms attribute of the root DSE, or an  
accessControlScheme attribute of each context prefix entry. That way a client
can look at an entry on a server and algorithmically determine whether it 
recognizes the scheme in use.  If the OID from at or near the entry doesn't 
match one or more OIDs coded into the client, then the client can't make any 
assumption about the access control model.  If it does match, then the client 
can swap in the appropriate parsers to interpret the access control model for 
the partition containing the entry.



Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.