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

[Ellen Stokes <stokes@austin.ibm.com>]

Mark,
Thanks for the comments. Response is embedded in each point below.
Ellen Stokes & Bob Blakley


At 04:00 PM 10/21/97 -0500, you wrote:
>
>Thanks for putting together this document.
>
>I have a few small suggestions of additions and requests for clarifications.
>
>0. Introduction 
>
>In ordinary drafts and RFCs defining protocols, the words "SHOULD" and "MAY"
>apply to options which an implementor has when implementing the protocol.  
>However, in this document I think these terms apply to options which an ACL
>designer has when specifying the protocol.  This requirements document may
have
>a "MAY" requirement of whether an ACL design needs to support a particular
>feature, but the designer can make it a "MUST" requirement for
implementation.
>
>In the description of "SHOULD": I suggest adding the phrase "in writing an
ACL 
>specification" following "ignore a particular item" to reinforce this.
>
>In the description of "MAY": I think that the paragraph needs to be
modified, 
>since there would be expected to be only one standards-track IETF access 
>control specification, not one specification per vendor.  I suggest instead
>  
> MAY - This word, or the adjective "OPTIONAL", mean that an item is truly 
> optional. The ACL specification needs not include the item. 

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.


>
>1. ACL administration over protocol
>
>In requirement (G3): I would like to strengthen "SHOULD" to "MUST".  IMHO an 
>IETF-defined LDAP access control system must be configurable over LDAP. 

Fine - what do others think?

>
>2. DN reuse 
>
>In requirement (G4): The last sentence makes assumptions on the specification
>of access control.  There could be a specification of access control in which
>there can't be stale ACLs (e.g. an entry is identified by a 
>DN+create timestamp).  I suggest the last sentence could be reduced to:
> 
>  The recreation of DN1 (and given to a different person) SHOULD be
protected.
>

How about: 

"The directory SHOULD support policy controlling re-creation of
deleted DNs, particularly in cases where they are re-created for the purpose
of assigning them to a subjec other than the owner of the deleted DN."

>3. Explicit denial
>
>In requirement (S8): by forbidding explicit denial, would that prevent an 
>access control configuration of 
>"The public can read all attributes EXCEPT the payrollCode attribute."
>
>or do you mean something else by explicit denial?
>

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".

So for example, the UNIX file system allows only "grant" rights; they are
"r", "w", and "x".  It also supports a "don't care" flag, which is "-".

So a UNIX file system ACL (well, mode bit vector to be precise) of the form

rwxr-x---

Means that the owner are granted rights to read, write, or execute the file
by this entry; 
Members of the owning group are granted rights to read or execute the file
by this entry;
Others are granted no rights by this entry.

In this syntax, there's no way to say "Joe *CAN'T* read the file".  The way
Joe is 
excluded from reading the file is by not putting him in any group which is
explicitly
granted "r", and relying on the default-deny semantics of the ACL
resolution algorithm
to lock him out.

There are many ways to implement semantics of the sort "The public can read
all
attributes EXCEPT payrollCode" without implementing explicit denial.  
One way is to group attributes and give each attribute group a separate ACL.

So, for example, you might define two attribute groups for a particular
directory
object:

normal-attributes INCLUDES ALL EXCEPT payrollCode
private-attributes INCLUDES payrollCode

Then you could have an ACL on the object which looks like this (assuming
that the
rights language contains the same set of "grant" rights as the UNIX file
system --
this of course isn't appropriate for directories but makes it easy to talk
about
the example):

ACL for "object1":

	normal-attributes:  PUBLIC "r--"
	private-attributes: PUBLIC "---" 

>4. Side effects
>
>In requirement (S13): rights management MUST have no side effects.  Could you
>include a definition of what you mean by side effects?  If I modify an
>access control subentry in an X.500 server to remove a particular ACI Item, 
>then the server could implictly deny access to aspects of user entries in
the 
>access control area, any may initiate a HOB Modify or Shadow supply
operation.
>Are these side effects?
>

Sorry; this text wasn't explicit enough.  Here's a more explicit version; this
defines what is meant by "rights management MUST have no side effects":

Granting a subject a right to an object MUST NOT implicitly grant any other
subject the
	same right to that object.

Granting a subject one right to an object MUST NOT implicity grant the same
or any other
	subject a different right to the same object.

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

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

Definition: An ACL's "scope" is defined as the set of directory objects
governed by 
the policy it defines; this set of objects is a sub-tree of the directory.

Changing the policy asserted by an ACL (by changing one or more of its
entries) MUST NOT
implicitly change the policy governed by an ACL in a different scope.


>5. Partitioning
>
>In requirement (U13): I would like to have two additional requirements.
>
>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.

First, I think you meant to say "...superior 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.

>
>An Administrator MUST be able to configure whether delegated access control 
>information from superior partitions is to be accepted or not.
>
>E.g. it would be likely that ou=research,o=ibm,c=us would want to accept the 
>access control rules of o=ibm,c=us (ou=research is an Access Control Inner   
>Area).  However, it is also possible that 
>ou=my company,o=dodgy listing service,c=us would not want to accept the 
>access control rules of o=dodgy listing service,c=us (o=my company is an 
>Access Control Specific Area).
>

OK, as long as the choice of WHICH administrator's decision is binding is
under control of the enterprise (i.e. enterprises should be able to decide
either that superior administrators' decisions rule, or that subordinate
administrators' decisions rule, depending on their organizational policy.
Some organizations are "top-down" and some are "bottom-up" in this regard.)

>6. Unauthenticated Modification
>
>In requirement (U15): Does the term "access" also include modification by
>unauthenticated users?

No.  So let's reword the requirement as:

U15. It MUST be possible to create publically readable entries which may be
read
even by unauthenticated clients.

>
>7. Access Control Priorities
>
>I would like to suggest two additional requirements for delegation.
>
>It MUST be possible for the administrator to configure the access control
>system to permit users to grant additional access control rights for entries
>which they create.
>
>(The previous requirements don't allow users to create private entries which 
>their friends can modify without asking the administrator each time they
>create an entry.)

Making this a MUST precludes use of Mandatory Access Control (a means of
restricting access based on sensitivity of the information and formal
authorization, such as clearance, of subjects to access info of such
sensitivity), 
i.e. it only allows Discretionary Access Control (the ability you describe in
your proposed requirement).  I can accept the requirement stated using SHOULD.

>
>It MUST NOT be possible for a user to modify access control rights to limit
>the rights of the administrator.

I disagree.  This states an explicit policy in the model.  Policies as such
are defined by the administrator and implemented via the model.

>
>8. Directory Management 
>
>I have an additional general requirement for the access control
specification.
>This could be combined with G3.
>
>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.  The parameters of the search operation are 
>defined by the access control specification.  If the specification allows
for 
>extensibility, then this search MUST also return information about the 
>extensions which are permitted or being used in the partition.
>

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

>
>
>Mark Wahl, Enterprise Directory Integration
>Critical Angle Inc.
>
>