Re: Comments on draft-ietf-ldapext-reqts-01.txt - repost

[Bob Blakley <blakley@dascom.com>]

David,

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

bb> Thanks to all for your comments.  My thoughts are prefaced by "bb>" in the
left margin.

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.

bb> The section may indeed be a little loose.  Replication is addressed
because of the need to insure that access policy
bb> is propagated when LDAP entries are propagated from one repository to
another during replication.  Authorization is
bb> of course part of secure access, though as you observe not the only part.
To pick a nit, ACLs do NOT govern a known
bb> identity's privileges -- that's what credentials do. ACLs govern what
rights are granted to the possessor of a particular
bb> set of privileges for the purpose of accessing a particular resource.

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.

bb> but probably not possible.  The point here is that since this document
solicits a security mechanism, tradeoffs should be
bb> made in favor of security rather than in favor of other quality
attributes.  You know it when you see it, right? :-)

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.


bb> I suppose we could fix this, but after long discussion in the working
group we've concluded that this is in fact wrong,
bb> and the model no longer defines attributes for ACL data.  So I think this
is more or less a dead letter.

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.

bb> A requirements document essentially solicits proposals; what this document
is saying is that people bringing forward proposals
bb> need to specify the order of precedence, and the combinator or combinators
in cases of equal precedence.  We felt
bb> that constraining proposers to make a SPECIFIC choice (e.g. union over
intersection, or vice versa) would be
bb> presumptuous; we certainly don't intend that an accepted proposal should
leave these matters underspecified -- however
bb> we do want to allow proposers to make decisions we might not make in each
case.  It's the job of the model document to
bb> define both the precedence rules and the combinators in case of equal
precedence.

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.

bb> This is a comment against the model document, not against the requirements
doc.

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.

bb> This isn't true if a directory externalizes its policy identifier to tell
other directories whether it's default-grant or default-deny.

Absence of policy should NEVER be interpreted as grant.

bb> Your opinion; used to be mine too.  I eventually conceded to a fair number
of customers who insisted that they didn't
bb> want the extra workload to define policy for resources everyone should be
able to see - they only wanted to define a
bb> policy if they wanted to restrict access to a resource.

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?

bb> You've got it exactly; this is the intended interpretation.

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.

bb> It can simplify policy creation, at the cost of making policy
interpretation and modification more difficult.  We opted to require
bb> a completely explicit model, on the grounds that there are fewer
"unwritten rules" to memorize.

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?

bb> Reasoning: sharing attributes among objects with identical policy makes it
easier to maintain policy integrity
bb> and alleviates problems of scale in large directories with mostly
homogeneous policies.
bb> Anticipated (example) implementation: entries will contain pointers to
ACLs rather than explicit ACLs.


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.

bb> That's why they pay us the big bucks....

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?

bb> Here again we didn't want to constrain implementors unduly; there are a
variety of ways to make sure this doesn't happen
bb> including, for example, specifying that the root DSA always has permission
to change the root entry's ACL (this is just
bb> an example, I'm not pushing for it as an implementation).  People are free
to be clever here.

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

bb> Sensitivity is in the eye of the beholder.  What's really meant here is
that the ACL model designers shouldn't stick slavisly to
bb> a "whole entry" granularity or a "individual attribute" granularity model;
they should instead consider providing means of
bb> grouping the attributes of an entry based on the administrator's view of
their sensitivities, and then allow administration of
bb> access to the "sensitivity groups".  An example of something like this is
public vs. private methods in OO programming
bb> languages...

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.

bb> I haven't an argument here' publicly readable attributes probably are
useful, as are publicly readable entries.

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?


bb> probably!


--bob

Bob Blakley (blakley@dascom.com)
Chief Scientist, Dascom


BEGIN:VCARD
VERSION:2.1
N:Blakley;Bob
FN:Bob Blakley
ORG:Dascom
TITLE:Chief Scientist
TEL;WORK;VOICE:+1 (512) 458-4037 x 5012
TEL;WORK;FAX:+1 (512) 458-2377
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;Plaza Balcones=0D=0A5515 Balcones Drive;Austin;TX;78731;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Plaza Balcones=0D=0A5515 Balcones Drive=0D=0AAustin, TX 78731=0D=0AUSA
URL:
URL:http://www.dascom.com
EMAIL;PREF;INTERNET:blakley@dascom.com
REV:19990526T184515Z
END:VCARD