Subject: Re: protocol: data hiding

From: "Jim Sermersheim" <[email-masked]>
Date: Mon, 09 Feb 2004 15:14:27 -0700

I like the notion of bringing this to the reader's attention, but I
dislike prescribing specific actions. How about something more like:
 
The matchedDN and diagnosticMessage fields and some result codes (such
as insufficientAccessRights, attributeOrValueExists and
entryAlreadyExists) may disclose the presence of specific data in the
directory. Access controls coupled with restrictive policies can be used
to protect against such disclosure.
 
Jim

>>> Hallvard B Furuseth <[email-masked]> 2/9/04 2:14:31 PM
>>>
A Security Consideration like this might be a good idea:

The matchedDN and diagnosticMessage fields and some result
codes (such as insufficientAccessRights, attributeOrValueExists
and entryAlreadyExists) may reveal the presence of specific
data in the directory. If access controls prohibit this, the
server must take care to instead act as if the data are not
present, or when that is not possible, to return a less
informative result code.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 09 Feb 2004 14:52:31 -0800

At 02:14 PM 2/9/2004, 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:
> 
>The matchedDN and diagnosticMessage fields and some result codes (such as insufficientAccessRights, attributeOrValueExists and entryAlreadyExists) may disclose the presence of specific data in the directory. Access controls coupled with restrictive policies can be used to protect against such disclosure.

I rather word the consideration to the implementor not the
user.
        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.

Kurt

> 
>Jim
>
>>>> Hallvard B Furuseth <[email-masked]> 2/9/04 2:14:31 PM >>>

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 11 Feb 2004 23:05:26 +0100

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

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.  Since I can't think of any other option, I
don't really care is that is stated as a suggestion or a mandate.

Also,

>         normal but also under error conditions.

s/both//.
s/presence the/presence of/.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 11 Feb 2004 18:14:52 -0800

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

>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

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