Comments on draft-ietf-ldapext-acl-model-02.txt

[David Ward <DSWARD@novell.com>]

Here are our comments and questions on the ACL model document.  We know there are a large number of comments, but we thought it would be best to post them as one group.  

comments from:  Brian Jarvis, Jim Sermershiem, David Ward
document:  draft-ietf-ldapext-acl-model-02.txt


Section 1:  Introduction

Same comments as review document (repeated here):  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 2:  Overview

The phrase "This policy data describes security-relevant characteristics of the requesting subject" needs clarification.  What is security-relevant about the subject?  The target object and its attributes are the security-relevant data.

The overview indicates the document will only discuss the wire format and "the instantiation of an access control model" will not be defined.  However, the document later discusses ACL attributes and syntaxes.  By defining attributes and their syntax in the directory, the document moves beyond wire format.  The language should be updated to reflect this.

The second bullet point in the overview indicates the document defines the LDIF format for ACLs.  However, the document has taken the approach of defining ACL attributes.  The LDIF language needs to be replaced with language indicating ACLs are defined as attributes. 


Section 4.1:  Access Control Activity Lifecycle

Four activities of the lifecycle are outlined as items the document will discuss.  The first two, creation / retrieval, of policy information, deal with accessing the ACL information.  However, the overview explicitly states "no mechanisms are defined ... to control access to the access control information". 

The last activity, replication of access control information, doesn't seem necessary.  If ACLs are expressed as attributes, no special replication functions are needed.  Regular replication mechanisms are sufficient (covered in the LDUP effort).


Section 4.2:  Access Control Information Model

"This document doesn't define formats for storage".  Again, the document defines attributes and attributes have a specific format (syntax).  


Section 4.3:  Bind and Credentials

This section is very wordy and basically just indicates the document doesn't define how authentication works.  The document should simply state authentication mechanisms are not defined here.


Section 5:  Access Control Information Schema

The Root DSE attribute "supportedACIMechanisms" is defined and it indicates which mechanisms are supported (LDAPv3, X500, other ).  Do these mechanisms indicate the "Rights Families" an application can expect to find?  For example, if the mechanism is LDAPv3, I can expect the rights defined in the LDAPv3 rights family.  Can there be multiple "Rights Families" associated with one mechanism?  What characteristics does the supportedACIMechanisms imply?

LDAPv3 attribute rights defined are: Read, Write, Search, and Compare.  What is the difference between search and compare?

LDAPv3 object rights are: "add" and "delete".  Modify DN is an LDAP operation, should there be a right for this operation?  

Many applications have an "explorer" like functionality that allows users to browse through the directory hierarchy.  This would be implemented using LDAP search.  Should the search (browse) right be applied to the object level instead of the attribute level?

What are the Manage, Use, Get, and Set rights?  Please clarify?


Section 6:  Access Control Parameters...

The definition of rightsFamily only includes rights (permissions), shouldn't it also mention scope, dnType, and subjectDN?

SubjectDN is defined as a DN or another string such as an IP address.  The requirements draft indicates subjects should be DNs.  It seems reasonable to restrict SubjectDN to only DNs.  It also simplifies things.  

The two well-known subjectDNs (public, this) should be added to the BNF.

Four operations are defined, ACI_GRANT, ACI_DENY, ACI_REPLACE, and ACI_DELETE.  The operations are not used in the controls or  extensions.  Are they just carryovers from earlier versions of the document?  Since ACLs are defined as attributes, there appears to be no need for these operations.


Section 7:  Access Control Information Controls

The first paragraph states:  "The access control information controls provide a way to manipulate access control information".  The controls are search controls.  Because they are search controls, "set" should probably be dropped and manipulate be changed to query.   Also, there are no controls for ldap_add and ldap_modify anymore.


Section 7.1.1:  getEffectiveRights Control

The getEffectiveRightsRequest is defined as :

                   getEffectiveRightsRequest ::= SEQUENCE {
                                    targetDN  LDAPDN,
                                    effectiveRightsRequest   SEQUENCE OF SEQUENCE {
                                                   rightsFamily  LDAPOID | "*",
                                                   whichObject   ENUMERATED {
                                                                             LDAP_ENTRY (1),
                                                                             LDAP_SUBTREE (2)
                                                                            },
                                                   dnType        LDAPOID | "*",
                                                   subjectDN     LDAPString,
                                     }
                    }

What is the purpose of the targetDN?  Isn't the target already specified as part of the regular search request?  

The request can include multiple effectiveRightsRequests (SEQUENCE OF SEQUENCE).  Is this to allow multiple subjectDNs to be specified in one request?  If this is the case, the information returned in the PartialEffectiveRightsList does not have the subject specified.  How can an application know to which subject the information applies?

What is the purpose of whichObject in the effectiveRightsRequest?  Our initial impressions were that it related to the targetDN.  For example starting at this target location, get the rights for this entry or this entry and subtree.  However, if this is the case, this is already specified as part of the search.

What is the purpose of dnType in the effectiveRightsRequest?  Is it calling out the type of the subjectDN (access-id, role, group)?  This does not seem necessary.  The directory already knows the subjectDN's type.  Or if dnType equals group/role, does this mean rights are to be calculated and returned for everyone in the group/role?  If the later is true, how are the rights returned in the PartialEffectiveRightsList for each member?  Each member of the group/role may have different rights (the rights acquired from the group/role membership and rights from other ACLs ).

In general, as a search control, get effective rights seems strange.  ACLs are regular attributes, and they can be retrieved using search.  However, calculating effective rights is a specialized function and it just seems to work better as a separate LDAP extension.  This control seems to extend search in an unintuitive way.
 

Section 7.1.2:  Response Control

The getEffectiveRightsResponse enumerates the result codes.  There isn't a result code defined for insufficient rights (50).  This is needed to indicate the individual doesn't have the necessary rights to perform the request.

How are effective rights returned for the special cases "[entry]" and "[all]"?  ACLs can be defined for the entire object or all attributes using these key words.  The document indicates "effective rights are returned with each attribute returned by the search result".  These special cases don't map to an attribute.

The PartialEffectiveRightsList contains a "rightsList" ENUMERATED type but there is no definition of  values.


Section 7.1.3:  Client-Server Interaction

"The getEffectiveRightsRequest Control requests the rights that MUST be in effect...".  The word MUST doesn't make sense here.  It makes more sense if the language is changed to "The getEffectiveRightsRequest Control requests the rights that ARE in effect...".


Section 7.2:  listSubjectRights Control

The purpose of this control is not clear.  The control appears to return the ACLs that exist on the targetDN.  Since the ACLs are attributes, the same thing could be accomplished with a regular search.  Is this just a carryover from earlier versions of the document?


Section 7.3:  specifyCredentials Control

This control provides a mechanism for authentication using some specified credentials.  Why is this control needed as part of the ACL model?  Authentication is the mechanism used to prove one's identity to the directory.  After the directory knows your identity, ACLs are used to govern access rights.


Section 8.1:  LDAP Get Effective Rights Operation

In general we feel using an extension is the best method for exposing the effective rights operation.  However, the questions outlined above for the getEffectiveRights control apply here, too.  

The get effective rights operation answers the following question:  What rights does subject A have on target B's attribute X?  Three pieces of information are necessary, subject, target, and attribute name.  The response is the rights the subject has on the attribute specified.  This is could be expressed in an extension defined as follows:

ldapGetEffectiveRightsRequest::= [APPLICATION 23]
             SEQUENCE {
                requestName      [0] <OID to be assigned>,
                requestValue      [1] OCTET STRING OPTIONAL }

                requestValue ::= SEQUENCE {
                              targetDN                  LDAPDN,
                              rightsFamily              LDAPOID,
                              attributeName          LDAPString | "[entry]" | "[all]",
                              subjectDN               LDAPString             	
                   }

The response could be defined as follows:

ldpGetEffectiveRightsResponse::= [APPLICATION 24]
             SEQUENCE {
                COMPONENTS OF LDAPResult,
                responseName     [10] <OID to be assigned> OPTIONAL,
                effectiveRights  [11] OCTET STRING OPTIONAL }

                effectiveRights ::= SEQUENCE {
                              rightFamily         LDAPOID,
                              rightsList           SEQUENCE OF permissions }

                permissions ::=  "a" | "d" | "r" | "s" | "w" | "c" 


Section 8.2:  LDAP List Subject Rights

Not needed.  Same comments as section 7.2


Section 9:  Operational Semantics of Access Control Operations

The first action references the "LDAP Update Access Extended Operation" and the "LDAP Update Access Control".  These don't exist in the document.  Are they just carryovers from earlier document versions?  If not, they should be defined.


Section 10.1:  LDIF Purpose

The language here discusses the reasoning for LDIF and the ACI work.  However, the ACI work has changed to define regular LDAP attributes for the access control information.  The LDIF language should probably be dropped completely and just focus on the ACI attributes.  It would be nice if the ACI attributes were defined earlier in the document.  The attribute information could possibly be merged with section 5.

The third paragraph states: "If the server does not support inheritance, the receiving server must expand any inherited information based on the scope flag".  While it is possible to expand ACL information initially, what happens when a new object is added to the subtree after the information has been expanded?  In a directory that supports inheritance, there is no problem.  In a directory that doesn't support inheritance, who knows?  It is probably implementation dependent.  The document should simply state inheritance is required for the ACL model to function correctly. 

Another rights inheritance question.  Does a subordinate object receive the rights granted to its parent?  For example assume the object, "cn=someUser, ou=someOU, o=someO", exists in the directory.  If rights are given to the parent object, "ou=someOU, o=someO", to read and write "attribute1" on the object "ou=anotherOU, o=anotherO", does the object "cn=someUser, ou=someOU, o=someO" also get these rights?  

In this situation, there would be an ACL on the target object "ou=anotherOU, o=anotherO" similar to the following:  
                        aci:  1.2.3.4#entry#access-id#grant;r,w;attribute1#ou=someOU, o=someO


Section 10.2.1:  VendorACI

What is the real value of this?  It appears to be nothing more than a place for proprietary information.  However, it assumes all vendors will be happy with placing all their proprietary information into one attribute.  For some vendors, it may make sense and for others it won't.  If the information is proprietary, vendors should name and expose it in a manner that makes the most sense.  Developers have to talk to the vendor to figure out the proprietary information anyway.


Section 10.2.2:  Policy Owner

There is a lot of  "implementation defined" language in this section.  It would be nice to clarify policies and make firm statements concerning expected behavior.  

The policy owner attribute syntax specifies a scope and subject.  Have you considered finer control that would allow you to call out specific attributes and/or rights?  For example: SubjectA can administer the telephone attribute, or SubjectB can set read/write privileges on attributes x, y, and z.


Section 10.2.3:  ACI

Paragraph two states:  "This is the composite of the permissions and resources to which the user is being granted or denied access".   The word "user" should be replaced with "subject".  Rights may be granted to many types of objects, not just users.

One page 33 there is an example of an ACI with an empty rights list.  
        aci:  1.2.3.4#subtree#group#cn=Dept XYZ, c=US

This is very strange and the document states the behavior is implementation defined.  If the behavior is implementation defined, what is the value of allowing this?  At least the action, <grant | deny>, should be required.  We feel this should be illegal and the BNF updated to not allow empty rights.

Does one of the actions, grant or deny, take precedence?  What happens if there are two identical ACIs except for the action?  One that grants read to attribute1, and one that denies read to attribute1.

The two special cases for attribute strings are described, [entry] and [all].  This is good but they may be more easily understood if the names where changed to [entry rights] and [all attributes rights].


Section 10.3:  Modifying the ACI values

Programmers will expect add, delete, and replace to work the same as any other attribute.  Any unique or implementation defined behavior is a surprise and will lead to errors.  It is our opinion that the problems and confusion are a result of the ability to specify multiple actions and attributes in one value.  This ability doesn't provide any new or unique functionality.  The same thing can be accomplished with multiple values in the ACI attribute.  We feel it is much simpler if an ACI specifies one action, permissions, and one attribute.  For example:  

        aci:  1.2.3.4#subtree#grant;a,d;[Entry Rights]#ou=DeptXZY, o=Org
        aci:  1.2.3.4#entry#grant;r;attribute1#cn=Joe, ou=SomeOU, o=Org

This allows programmers to get and set specific rights for an attribute without having to worry whether the attribute is also named in some other compound value.  

You will notice we also left out the dnType.  This just basically calls out whether the subject is a group, role, or access-id (individual object).  The directory can figure this out.  Is it really necessary to require this information?

If we keep things simple, this entire section describing the behavior for modifying ACI values is not necessary.  They behave just like any other attribute.


Section 10.4:  BNF

Assuming that the LDAPv3 rights family (5.2.1) and the IETFFamilyOID (10.2.3) are really the same thing, it may be helpful to separate the LDAPv3/IETFFamilyOID from the rest of the document. Since the model document describes a rights family in terms of scope, dntype, subjectdn and permissions, those things should all be well defined in section 5.2 (there is already some degree of definition there).  Then, since the values of those four types may change with different rights families, the values themselves shouldn't be brought up throughout the rest of the document.

In other words, the BNF shouldn't contain values for scope, dnType, subjectDN, or permissions.  Instead, it should describe the valid values for these in a separate IETFFamilyOID BNF section.  The aci BNF should be a framework with which one may insert the BNF of *any* familyOID to produce a fully functional BNF.  This way, when the X.500 rights family is described, it will fit more naturally into the document.

This same notion applies to the controls and extensions as well.  On the other hand, if this document is meant to be used solely as an IETFFamily ACL model document, forget about it (but that should be stated somewhere).