Re: [ldapext] draft-zeilenga-ldap-assert-05 notes

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:18 PM 2/24/2005, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 09:35 AM 2/23/2005, Hallvard B Furuseth wrote:
>>>draft-zeilenga-ldap-assert-05.txt says:
>>>> 4.  Security Considerations
>>>>
>>>>   As with any general assertion mechanism, the mechanism can be used to
>>>>   determine directory content.  Hence, this mechanism SHOULD be subject
>>>>   to appropriate access controls.
>>>
>>>I suggest to add something like:
>>>
>>>    ... preferably the same access controls as search filters.
>>
>> Is there a search reason behind this preference?
>
>It seemed to fit best the few access control models I know of.  If a
>baseobject search for "(&)" or "(objectClass=*)" returns the entry but a
>search for some other filter does not, I think Modify with an assertion
>of that filter should cause assertionFailed.  But I must admit I haven't
>thought through all the variants of this control and access controls
>even in the models I do know.
>
>> I rather not state a preference as part of a security considerations
>> unless there is a good security related reason for that preference.
>
>The security reason I'm aware of is that I got it very wrong the
>first time I thought of implementing access controls for this control.

Wrong?  or just not the way you thought it should be for the
particular access control you were using?

Saying "SHOULD be subject to appropriate access controls" implies
that the implementor should careful consider what is appropriate within
the particular access model used in that implementation.  I find it
difficult to suggest what might be appropriate in general as that
requires, I think, making some assumptions about the access control
model.

>>> The implementor might find the same access controls as for Compare
>>> natural, but the server admin might e.g. not want substring matching to
>>> be possible - and he could have written the Compare ACLs knowing that
>>> Compare can't do substring matching.  Or one might mistakenly use the
>>> same ACLs as for the "basic" operation being performed, e.g. Modify.
>>
>> It seems to be your statements depend greatly on what the
>> access control model is...  I can certainly envision models
>> where that would not be a mistake.
>
>Can you give an example?  Hypothetical or not.

I think it would be reasonable to allow a user authorized to
perform a modify to make that modify conditional.  In a model
where "search" rights includes "read" rights, I don't see in
necessary to requires "search" rights.

>BTW, another point:  The draft says
>
>>  When the control is attached to an LDAP request, the processing of the
>>  request is conditional on the evaluation of the Filter as applied
>>  against the target of the operation.
>
>Except that the control should not prevent the return of a referral, I
>presume.

If the server does not hold the target, it should (as it would
normally) return a referral (or noSuchObject) as appropriate.


>-- 
>Hallvard
>
>_______________________________________________
>Ldapext mailing list
>Ldapext@ietf.org
>https://www1.ietf.org/mailman/listinfo/ldapext


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext