Comments to draft-ietf-ldapext-reqts-01.txt

[David Ward <DSWARD@novell.com>]

We have been reviewing the ACL requirements and model documents.  Following are comments to the requirements document.  

comments from:  Brian Jarvis, Jim Sermershiem, David Ward
document:  draft-ietf-ldapext-reqts-01.txt


Section 1:  Introduction

The introduction uses the terminology "securely access", "replicate", and "distribute" directory information.  ACLs do not control server to server replication or data distribution.  They also do not deal with directory authentication or secure access (ie.  SSL encryption).  ACLs only govern the authorizations (privileges) a known identity has.  The language should probably be changed to reflect this.  


Section 3.1:  General

G2:  "When in doubt, safer is better".  What does "safer is better" mean?  To some people safer may mean provide default rights for read, write, etc.  For others, it may mean provide no rights as defaults. Clarification would be helpful.

G3:  "Access control information MUST be an LDAP attribute".  The language implies there may only be one LDAP ACL attribute.  However, the model document refers to multiple attributes.  More general language such as "Access control information MUST be represented as LDAP attributes" may be better.


Section 3.2:  Semantics / Policy

S2, S3:  "More specific policies must override less specific ones".  This indicates there must be some precedence placed upon ACL types (individual, group, role) for evaluation purposes.  What is this precedence?  S3 indicates rights of equal specificity should be combined in some way (union or intersection).  There is a big difference between a union and intersection of rights.  Should this really be left to individual implementations?   If directory interoperability is expected, one would anticipate the set of rights directory vendor A calculates would be the same as directory vendor B calculates.  However, this may not be the case when vendor A chooses to calculate the "complete" set of rights using a union and Vendor B uses an intersection.   A simple approach would be to define the "complete" set of rights a subject receives as the union (aggregation) of all individual, group, and role ACLs.
  
S4:  This section talks about default ACL policies that SHOULD be applied to an object upon creation.  However, the model document does not discuss these defaults.  Is reasonable to expect they are created and administered in the schema as object class information?  For example all Organizational Unit objects are given default ACLs a,b,c and all User objects are given defaults x,y,z.  This needs to be clearly called out.  

S11:  "Absence of policy SHOULD be interpretable as grant or deny."  If LDAP ACLs are expected to interoperable between LDAP directories, this can not be left to the directories' discretion.  Absence of policy should NEVER be interpreted as grant.

 S13:  This section indicates there are no implied rights.  This means if Subject A is given write rights to Object B, Subject A does not implicitly have read rights.  Subject A must explicitly be given both write and read rights.  Is this the desired effect?  Or is it reasonable to expect that a subject with write access also implicitly has read access?  Implicit rights enable mechanisms like a supervisor right.   Any subject given supervisor rights, has all access rights to the object.  This can be good because it can simplify administration.

S14:  This section discusses policy sharing.  The concept of ACL inheritance means an object's "complete" set of rights include ACLs on the object and ACLs inherited from it's parent, grandparent, etc.  A parent's ACLs are "shared" with its subordinates.  However, it also mentions sharing across different subtrees.  The model document doesn't discuss this "across subtree" sharing.  Can you provide more information about "across subtree" sharing?  What is the reasoning, anticipated use, etc?


Section 3.3:  Usability

U3:  This section indicates it SHOULD NOT be possible for an administrator to inadvertently lock all users out of the directory.  If this means preventing an administrator from accidentally creating "black holes" of no administrative rights in a directory, it can be very difficult to actually prevent.  ACLs are used to grant or deny access and administrators MUST understand them.  Are you implying there should be some kind of "super user" or other way to circumvent any or all access controls?  

U5:  "Administrators SHOULD be able to administer access to directories and their attributes bases on their sensitivity?"  What is meant by sensitivity?  

U15:  "It MUST be possible to create publicly readable entries".  Does this mean certain object classes are defined as "public read" and when instances of the object class are created, all their attributes are public?  It seems more reasonable to declare publicly readable attributes.  For example, declaring the CN attribute as "public read" means any client can read an object's CN attribute (authenticated or unauthenticated).  The model document does not discus a mechanism for doing this.

U18:  This section talks about configuring access to the access control system.  However, section 2 of the model document states "no mechanisms are defined ... to control access to the access control information".  If it is listed in the requirements document as a SHOULD, should not the model document at least discuss it and present an approach? 
 

David Ward (dsward@novell.com)
NDS SDK Group