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

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 23 Feb 2005 18:35:28 +0100

draft-zeilenga-ldap-assert-05.txt says:

> 3.  The Assertion Control
>
>   The control is appropriate for both LDAP interrogation and update
>   operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN
>   (rename), and Search.  It is inappropriate for Abandon, Bind nor
>   Unbind, and Start TLS operations.

I expect "including..." means it's also appropriate for the Password
Modify Extended Operation (RFC 3062)?

Is Add intended to be part of the above list?  Kurt stated in thread
'Assert I-D.', 22-23. jul 2003, that he would change the control to not
be applicable to Add - since the entry is not yet present to be compared
with.  Though the thread can be read as keeping Add anyway and compare
with the entry to be added.

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

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.

-- 
Hallvard

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 23 Feb 2005 22:31:36 -0800

>Modify Extended Operation (RFC 3062)?

I consider Password Modify Extended Operation to be an "other"
operation, as in:
  Other documents may specify how this control applies to other LDAP
  operations.  In doing so, they must state how the target entry is
  determined.

I'll change the text to precisely state which requests the
control is appropriate for.

>Is Add intended to be part of the above list? 

I intend to remove Add from the list. 

>Kurt stated in thread

Is there a search reason behind this preference?  I rather
not state a preference as part of a security considerations
unless there is a good security related reason for that
preference.

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

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 24 Feb 2005 21:18:49 +0100

Kurt D. Zeilenga writes:
> 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.

> where that would not be a mistake.

Can you give an example?  Hypothetical or not.

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.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 25 Feb 2005 12:06:50 -0800

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

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

>Except that the control should not prevent the return of a referral, I

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 26 Feb 2005 17:55:31 +0100

Kurt D. Zeilenga writes:
>> (...)

Different from how I thought it should work is wrong enough when I'm the
one who did it:-)  Which doesn't mean anyone else would do the same, of
course.

> requires, I think, making some assumptions about the access control

Me too, now that I've thought about it.  "Same as for filters" was too
broad for what I was trying to address; I should at least have said
filters in baseobject searches, since one could have different access
controls for baseobject searches and other searches.  So I can well
imagine there are other ways I haven't thought of.

Still, I do think there are pitfalls and it would be useful to flesh out
the issue somewhat.  See below.

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

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.  That may even be a
correct interpretation of the draft's literal wording.  Are access
checks part of "processing" the operation, which is only done if the
assertion succeeds?

With some caveats, the same seems to me to apply if <foo> and <bar> are
the same attribute.  If access is set so that one can write but not test
an attribute, there is presumably some reason for it.  Allowing people
to provide secret input to some questionnaire, maybe.  But in that case
one can in any case simulate an equality filter by attempting to add and
remove again the value to be tested.

> In a model where "search" rights includes "read" rights, I don't see
> in necessary to requires "search" rights.

Well, in that model, to require "same access controls as search filters"
would require "read" rights.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 26 Feb 2005 10:27:30 -0800

>imagine there are other ways I haven't thought of.

I note that the server might not even implement the Search operation,
so saying same as "search" or same as "search filters" could have
some odd implications.

>the issue somewhat.  See below.

Please feel free to offer specific text for consideration.

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

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.

>all access controls before checking the assertion.

The access control model may have "don't disclose on error"
provisions.

>That may even be a

I generally presume there will be access checks in different
parts of the overall processing of the request, including
in finding the target object, performing the assertion, and
performing the "normal" processing.

>remove again the value to be tested.

Correct.  Or use no-op control as I demonstrated above.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 27 Feb 2005 22:14:21 +0100

> To see if that hidden <bar> exists.  Or:

Huh?  None of these refer to attribute bar, only to an attribute value
of foo.

> these assertions are necessary to perform the operation.

Yes.  Still, only equality assertions, which fits Compare access
more than general search (filter) access.

> The access control model may have "don't disclose on error"

True enough.

-- 
Hallvard

---

From: John McMeeking <[email-masked]>
Date: Mon, 28 Feb 2005 08:43:29 -0600

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

---

From: "Pierangelo Masarati" <[email-masked]>
Date: Mon, 28 Feb 2005 19:33:05 +0100 (CET)

> dictated by the access control policy.

There's some development ongoing in OpenLDAP's slapd on this; it's not in
a very representative piece of software though (back-sql), but I'm
planning to extend it to other backends.  All operations support the
draft-zeilenga-ldap-assert control, and, whenever appropriate, if an error
is to be returned, including assertionFailed, the associated object is
checked for "disclose" access to the "entry" pseudo-attribute.  If no
disclose access is granted, noSuchObject is returned instead of the real
error.  Regular access checks related to filter testing apply.

p.

-- 
Pierangelo Masarati
mailto:[email-masked]

    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497