Re: protocol: data hiding

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

At 02:05 PM 2/11/2004, Hallvard B Furuseth wrote:
>Jim Sermersheim wrote:
>
>> I like the notion of bringing this to the reader's attention, but I
>> dislike prescribing specific actions. How about something more like:
>
>For diagnosticMessage, I agree.
>
>Not sure about matchedDN.  The options I can think of are to act as if
>the entry is not there, or to not return a matchedDN at all.  However,
>with the latter behaviour, a user who knows the server well can
>sometimes deduce that an expected but missing matchedDN indicates a
>hidden entry.  So I think the text should at least mention that data
>is best hidden by pretending it is not there.

Note that matchedDN, like diagnosticMessage, are not OPTIONAL
fields.  They must always be present in the response.  However,
there value can be the empty string.

Beyond this, I agree with your sediment that you need to
careful in what you return in matchedDN.  If the value of
matchedDN is conditional in the implementation (that is,
the server does not always return the root DN), a client
may be able to deduce information from values provided.
And if additional information is available, such as the
naming context(s), it becomes even easier to deduce
information from the values provided.


>As for the result code, I would like the text to at least suggest that
>one may return a less informative result code.  Otherwise it may not be
>clear to an implementor what he can do when some revealing result code
>should normally be returned.

Note that more general is not necessarily less informative
to the attacker.


> Since I can't think of any other option, I
>don't really care is that is stated as a suggestion or a mandate.

I think it comes down to the server being free to return what
it considers to be the most appropriate code.  The most
appropriate code may not be the most specific.

Kurt


>Also,
>
>Kurt D. Zeilenga wrote:
>
>>         The matchedDN and diagnosticMessage fields, as well as some
>>         resultCode values (e.g., attributeOrValueExists and
>>         entryAlreadyExists), could disclose the presence the
>>         specific data in the directory where not subjected to
>>         access and other administrative controls.  Server
>>         implementators should provide access control mechanisms
>>         which not only restrict access to information under both
>>         normal but also under error conditions.
>
>s/both//.
>s/presence the/presence of/.
>
>-- 
>Hallvard