Subject: RE: [ldapext] draft-ietf-boreham-numsubordinates-01.txt

From: "Andrew Sciberras" <[email-masked]>
Date: Mon, 3 Nov 2003 10:37:11 +1100

>I feel that numsubordinates should return 0 when hassubordinates would
>return FALSE.  Since hassubordinates can include subentries,
>numsubordinates should also.
>
>John  McMeeking
>

Hi,

I think that subentries should not be included in the numSubordinates count.

If a use-case for the numSubordinates is to aid a GUI in deciding (for
browsing purposes) if an entry is a leaf, then returning 0 (zero) for an
entry with one or more subentry's and zero subordinate entries is
acceptable. This is because, under your general browsing and searching type
operations, subentries are not considered.
If the GUI was being used for Administrative purposes, where subentries may
wish to be explored, then simply checking if the entry is an administrative
point should accomplish this.

Another possible use-case for the numSubordinates attribute, which has been
expressed on this list, is for making decisions as to whether the entry is a
leaf for deletion purposes. Ludovic correctly pointed out that having
numSubordinates == 0 and getting a NON_LEAF error when deleting would be
confusing.
I don't believe a use-case of numSubordinates should be to identify if an
entry is a leaf for deletion purposes. Aside from ignoring subentries, the
scenario of numSubordinates == 0 and a NON_LEAF error will occur when the
user does not have sufficient permissions for the subordinate entries to be
included within the numSubordinates count.

On the topic of access control... The draft states:
'Servers MUST ensure that the value returned in the numSubordinates
attribute to clients is consistent with the view that client has of other
server contents.'
It has been established that this means that Access Controls should be taken
into consideration when returning the numSubordinates value.
I think the draft should be a little more specific though. Depending on what
the intended use-case of numSubordinates is, a statement should exist
regarding which permissions should be assessed when returning a
numSubordinates value.
E.g..
* Is the decision based on modify or read permissions?
* What happens if the entry's DN can be returned in a search, but the user
is not allowed to browse its contents?
* Which Access Control specification are we referring to? (BAC as defined in
X501, or the old draft-ietf-ldapext-acl-model-xx.txt)

Not including subentries within the numSubordinates count does introduce an
inconsistency between the numSubordinates and hasSubordinates attributes.
Is it the intention of this specification to maintain the some level of
consistency?
If so, are you including Non-Specific Subordinate References or child family
members in the numSubordinates count? Whilst NSSR and child family members
are both X.500 things, LDAP based Internet Drafts of each have existed at
some point in the past.

Regards,
Andrew Sciberras
Adacel Technologies.

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Tue, 11 Nov 2003 07:55:35 +0100

> X501, or the old draft-ietf-ldapext-acl-model-xx.txt)

You're raising some interesting issues regarding access control. After 
thinking about it I'd like to see that the statement above removed from the 
draft. The value of numSubordinates should not try to reflect the client's view.

Ciao, Michael.

---

From: "David Boreham" <[email-masked]>
Date: Mon, 10 Nov 2003 23:49:34 -0800

> draft. The value of numSubordinates should not try to reflect the client's
view.

The original motivation behind the statement in question was
to avoid leaking information otherwise restricted by access control,
via the numSubordinates attribute.

Of course any implementation which actually does generate
a different numSubordinates value depending upon access
control to the subordinate entries is likely to be rather inefficient.

I'm not aware of an implementation which actually does this.

So provided there aren't objections, I'm happy to remove the
statement.

It may be appropriate to add something to the effect that
access to the numSubordinates attribute by a client may
compromise attempts to restrict access to the subordinate tree.

I don't believe that the specific access control mechanism
matters here (but correct me if I'm wrong).

---

From: Michael Ströder <[email-masked]>
Date: Tue, 11 Nov 2003 09:07:09 +0100

David Boreham wrote:
 >Michael Ströder wrote:
>>thinking about it I'd like to see that the statement above removed from
>>thedraft. The value of numSubordinates should not try to reflect the client's
>>view.
> 

But this can't be achieved without raising serious implementation issues.

> compromise attempts to restrict access to the subordinate tree.

Simply add a note under security considerations. One can easily configure 
access control like to any other attribute.

Ciao, Michael.

---

From: "David Boreham" <[email-masked]>
Date: Sat, 29 Nov 2003 17:35:34 -0800

>access control like to any other attribute.

Agreed. From memory there was an earlier draft of
the document which was written this way, I'm happy
to regress back to that :)