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

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

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. 

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. 

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.

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?

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?

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.

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

6. Unauthenticated Modification

In requirement (U15): Does the term "access" also include modification by
unauthenticated users?

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

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

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.



Mark Wahl, Enterprise Directory Integration
Critical Angle Inc.







>From list@glacier.mcom.com Mon Nov 03 21:18:18 1997
Return-Path: <list@glacier.mcom.com>
Delivered-To: ldapext-archive@critical-angle.com
Received: (qmail 1013 invoked from network); 3 Nov 1997 21:18:08 -0000
Received: from h-205-217-233-39.netscape.com (HELO glacier.mcom.com) (205.217.233.39)
  by folder.critical-angle.com with SMTP; 3 Nov 1997 21:18:08 -0000
Received: (from list@localhost) by glacier.mcom.com (8.7.3/8.7.3) id NAA24149; Mon, 3 Nov 1997 13:03:36 -0800 (PST)
Resent-Date: Mon, 3 Nov 1997 13:03:36 -0800 (PST)
Message-ID: <C17B22BA6992CF11857C00805FD4098202856B1E@red-94-msg.dns.microsoft.com>
From: Chris Weider <cweider@MICROSOFT.com>
To: "'ietf-ldapext@netscape.com'" <ietf-ldapext@netscape.com>
Subject: Comments on draft-stokes-ldapext-acl-reqts-00.txt
Date: Mon, 3 Nov 1997 13:02:45 -0800 
X-Mailer: Internet Mail Service (5.5.1939.0)
Resent-Message-ID: <"8uzbG1.0.Hv5.dmZNq"@glacier>
Resent-From: ietf-ldapext@netscape.com
X-Mailing-List: <ietf-ldapext@netscape.com> archive/latest/12
X-Loop: ietf-ldapext@netscape.com
Precedence: list
Resent-Sender: ietf-ldapext-request@netscape.com

Comments on 'Access Control Requirements for LDAP'

The most general comment is that this document tends to conflate a number of
areas: access control semantics (what are the behaviors?), administration of
access control, and wire format for access control lists. A wire format
requirement would be, for example, "When ACLs are set via LDAP, the names of
the security principals MUST be DNs".  A semantic requirement would be "When
a new object is created, if an ACL is not otherwise specified during
creation, one MUST be created for it through a method that allows end users
to determine the default ACL. That is, the default ACL applied during
creation must be able to be set of specified by the end user or
administrator". 

Many of the comments I have tend to be aimed at teasing these issues apart.

Specific comments

G3: Text-> ACL administration SHOULD be part of the LDAP protocol
Comment: What does this mean? ACL administration is already a part of the
LDAP protocol if ACLs are implemented as specific attributes in each
entry.... that makes them readable and writeable through LDAP. Did you mean
something more?

G4: Text: Object reuse protection SHOULD be provided and MUST NOT inhibit
implementation or object reuse.
Comment: This comes to the first of my major sticking points. Our LDAP
implementation allows DN reuse because all access control is based on UIDs
(GUIDs, in our case). I think that the current overloading of DNs as: 1)
navigational information 2) location information and 3) identity information
has caused us too many problems. If primary entry identification and
security can be done on UIDs, that solves the rename and reuse problems.
This also solves some of the problems listed later in the document. 

Also, enforcing no name reuse also causes scaling problems. Are you supposed
to put timestamps in DNs to ensure uniqueness? Are you supposed to store all
the old DNs around? For how long? Years? Decades? Millenia?

The statement on space freeing is an implementation detail and is outside
the scope of the LDAP protocol. If implementors choose not to zero their
storage, there's nothing we can do about it.. the market will decide that
their implementation can't be trusted.

S2: Text-> More specific policies must override less specific ones...
Comment-> We don't have any metrics for security principal specificity. I'm
not sure we can create a partial ordering that will satisfy everyone, and in
any case, administering it will be a nightmare. I think we need to rethink
this. Note that this comment also applies to S3.

Also, one of MS's basic tenets has been that groups are first order security
principals. I think this is the correct approach.

S5: Text-> Access SHOULD NOT be enabled on the basis of attributes which the
directory administrator or his organization cannot control (e.g. groups
whose membership is administered by another organization).

Comment: We're working in a distributed system. Part of the beauty of that
is that it should allow you to base access on groups from other
organizations.  Delegation implies trust. If you don't trust a given
organization, don't include security principals from it. But don't lock it
the possibility of doing it.

S7: Text-> Humans SHOULD NOT be required to manage access policy on the
basis of attributes which are not "human-readable".
Comment: What does this mean? Isn't this a usability requirement? And
wouldn't the UI be responsible for most of this? And I could argue that DNs
are not particularly human readable, either....

S8: Text-> Explicit denial SHOULD NOT be supported.
Comment: Explicit denial allows for much easier administration. But what
does 'don't care' mean?

S9: Text-> The system MUST be able to support either default -grant or
default-deny semantics.
Comment: Default Grant would make any security evaluation (for example, C-2
certification) vastly more complicated since the discretionary access model
becomes difficult to express.

S10: Text-> The system MUST be able to support either union semantics or
intersection semantics for aggregate objects.
Comment: What is an aggregate object? It seems to me that you're implying
here that access control is set at the 'object class' level rather than the
entry level. That seems counter-intuitive.  Since most access control is set
at the entry level (or at the parent level....) this would mean that we
would need another set of specificity metrics to determine whether the
'object class' ACL overrides the 'parent' ACL. I think we have a confusion
of models here.

S11: Text->Absence of policy SHOULD be interpretable as grant or deny.
Comment: Does this mean that if an entry has no ACL, it gets the default?
The second sentence implies the partial ordering of ACLs again.

S12: Text-> ACL policy resolution MUST NOT depend on the order of entries in
the ACL
Comment: Why? The only way to get around this is to have the partial
ordering of ACLs that I've been saying is a bad idea. We may have to specify
an order-dependent wire encoding format for ACLs, but I don't think that's a
problem.

S13: Text-> Rights management MUST have no side effects
Comment: What is rights management? What is a side effect?

U2: Text-> Subjects MUST be drawn from the "natural" LDAP namespace; they
should be DNs.
Comment: Why? You're attempting to mandate implementation. It's cleaner and
more flexible to state that whenever subjects are transmitted between
machines, they must be transmitted in DN format (i.e. the wire
representation is a DN. 

U3: Text-> Is SHOULD NOT be possible via ACL administration to lock all
users, including the administrator, out of the directory
Comment: This assumes a single-administrator model that doesn't accord with
customer's needs from the directory. Also, 'super-user' privileges like this
can be very dangerous.

U4: Text-> Administrators SHOULD NOT be required to evaluate arbitrary
Boolean predicates in order to create or understand policy.
Comment: This is a UI issue, again determined by the market. But U1 is
correct, keep it simple.

U6: Text-> Management of access to resources in an entire subtree SHOULD
require only one ACL.
Comment: What about junction points in the subtree? Am I supposed to be able
to propagate ACLs across subordinate references? And should they also flow
across aliases?

U10: Text-> Control of access on a per-user granularity MUST be supported
Comment: What does this mean? That users should be security principals?

Section 3.4 Nested groups.

I think nested groups MUST be supported.