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

[John McMeeking <jmcmeek@us.ibm.com>]

I know how I would expect some servers to handle this control, but I don't
think that guidance would necessarily apply to other access control models.
I can offer the following text which might address Hallvard's concerns as I
understand them.

Access control policy SHOULD be applied to processing of the assertion
control value.  Use of the assertion control might enable a client to
obtain information about an entry it does not have authority to.  A result
code associated with authority to evaluate the control assertion ( e.g.
insufficientAccess or assertionFailed) might also reveal information that
violates access control policy; in such cases, the result code should be
dictated by the access control policy.


John  McMeeking


Hallvard B Furuseth wrote on 02/27/2005 03:14:21 PM:

> Kurt D. Zeilenga writes:
> >At 08:55 AM 2/26/2005, Hallvard B Furuseth wrote:
> >>Kurt D. Zeilenga writes:
> >>> (...)
> >>> I think it would be reasonable to allow a user authorized to
> >>> perform a modify to make that modify conditional.
> >>
> >> I hope not, if you mean conditional on any part of the entry.  Then if
I
> >> have Modify access to attribute <foo> in an entry but attribute <bar>
is
> >> hidden from read/search/compare by access controls, I can subvert
those
> >> access controls by e.g. trying remove a non-existent value from <foo>
or
> >> modify it to contain the same value as before, conditional on a <bar>
> >> filter.  noSuchAttribute or success reveal that the filter matches the
> >> "hidden" value of <bar>.  assertionFailed reveals that it does not.
> >
> > Ah, but the client could have used its modify rights to do:
> >         changetype: modify
> >         delete: foo
> >         foo: bar
> >         -
> >         add: foo
> >         foo: bar
> >         -
> >
> > To see if that hidden <bar> exists.  Or:
> >         control: no-op
> >         changetype: modify
> >         add: foo
> >         foo: bar
> >         -
>
> Huh?  None of these refer to attribute bar, only to an attribute value
> of foo.
>
> > My point here is that "right to modify" often implies a right
> > to make assertions, at least certain kinds of assertions, as
> > these assertions are necessary to perform the operation.
>
> Yes.  Still, only equality assertions, which fits Compare access
> more than general search (filter) access.
>
> >> Come to think of it, that can work even without Modify access.
Getting
> >> insufficientAccessRights instead of assertionFailed can reveal that
the
> >> assertion succeeded, unless the server implementor took care to check
> >> all access controls before checking the assertion.
> >
> > The access control model may have "don't disclose on error"
> > provisions.
>
> True enough.
>
> > (...)
>
> --
> 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