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

["David Chadwick" <d.w.chadwick@zetnet.co.uk>]

> From:          Chris Weider <cweider@MICROSOFT.com>

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

Chris, I see your implementation as one way of implementing G4. I 
dont see this as conflicing in any way with the requirement. Do you?

> Also, enforcing no name reuse also causes scaling problems. 

I did not read this as being a direct implication of G4.

> S2: Text-> More specific policies must override less specific ones...
> Comment-> We don't have any metrics for security principal specificity. I'm

These are pretty easy to establish. We just need to agree on them, 
for example
Everyone (i.e. public)
Everyone who works for my company
Everyone in my department
Just Me


> not sure we can create a partial ordering that will satisfy everyone, and in
> any case, administering it will be a nightmare. 

I think if you get the metrics right, it actually makes 
administration  EASIER


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

I tend to agree with you here, Chris
> 
> S8: Text-> Explicit denial SHOULD NOT be supported.
> Comment: Explicit denial allows for much easier administration. But what
> does 'don't care' mean?
> 

What is the rationale for ruling our explicit denial?

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

Default grant is dangerous, once systems are rolled out to thousands 
of administrators. We have already seen in the EMA directory 
challenge that some systems came pre-configured with a generous grant 
access control policy, and less than meticulous administrators were 
suddenly surprised to find entries being modified without their 
explicit authorisations. Its better to have a plumber come and fix up 
a water supply and leave with the tap switched off, rather than the 
other way around!

> 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?
> 

I think X.500 got it right here, in that it separates administration 
of the DIT, and subtrees, from the actual distribution of these 
between servers. If LDAP sticks to this model, then your issue about 
subordinate references becomes a non-issue. However, an alias is a 
pointer into someone else's subtree, so your should not be able to 
control access to the aliased entry in the alias. (although you 
obviously could control who has access to the alias pointer, and 
thereby indirectly control access to the aliased entry via your 
alias)

David
***************************************************
David Chadwick
IT Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 370 957 287
Email D.W.Chadwick@iti.salford.ac.uk
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
***************************************************