Subject: RE: C LDAP API: security considerations

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Sat, 13 Nov 1999 23:03:05 -0800

Suggest one plausible way in which it is possible to specify policy to an
application to do anything with the flexibility you insist must be present.

I.e., suppose the application is informed that it has been given a referral.
When and how will it decide to chase it, and when not?

Applications have no idea how to answer the above question. Neither do
users. If there were to be a mechanism to answer that question, and a way to
specify the policy for answering it, they should be _below_ the level of the
LDAP API, so that use of the mechanism and enforcement of the policy would
_not_ depend on all the applications doing the right thing, since experience
suggests that will never happen.

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Saturday, November 13, 1999 12:37 PM
> To: [email-masked]
> Subject: Re: C LDAP API: security considerations
> 
> 
> After some additional thought on this matter, I believe it
> inappropriate of API implementations to chase referrals without
> application interaction.  An API implementations should
> not assume the application's trust in the server providing
> the knowledge information extends to the referenced server.

Why? If the application trusts the first server to give correct answers, why
shouldn't it trust the servers to which it gives referrals?

> 
> A client application should be in direct control of which
> servers it does or doesn't connect to.  A client application
> should be in direct control of which request are submitted
> to servers.  A client application should be in direct control
> of which information is provided with each request.
> 
> I suggest that the default behavior of API implementations
> should be to NOT chase referrals.  I suggest we extend
> the API specification to provide a mechanism to allow
> applications that wish to progress the operation to do so
> under the application's control.  If the application fails
> to utilize this mechanism, the API implementation should
> not chase the referral.

I suggest that the default should be to chase referrals, and that an
application which is worried about chasing referrals should have a way to
opt out by providing a mechanism such as you suggest.

If referral chasing is not easy for applications, it won't usually be done.

If referral chasing is not usually done, then the freedom of a server to
partition its NC onto several servers with referrals to bridge them will be
eliminated.

> 
> I also suggest that we then add a security consideration
> to the C LDAP API I-D that encourages applications to
> interact with users to determine if chasing is appropriate.

Nonsense. Users always say "yes".

Paul

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 15 Nov 1999 02:50:28 -0800 (PST)

Paul Leach wrote:

> Suggest one plausible way in which it is possible to specify policy to
> an application to do anything with the flexibility you insist must be
> present.
> 
> I.e., suppose the application is informed that it has been given a
> referral. When and how will it decide to chase it, and when not?
> 
> users. If there were to be a mechanism to answer that question, and a
> way to specify the policy for answering it, they should be _below_ the
> level of the LDAP API, so that use of the mechanism and enforcement of
> the policy would _not_ depend on all the applications doing the right
> thing, since experience suggests that will never happen.

I think the scenario under discussion is a client app talking to its
friendly local directory service, which it normally talks to in an
authenticated way since that lets the DS provide it with good service, but
for some requests the local DS provides as an answer a referral to some
other DS.  The policy decisions of interest are whether the client
(a) should do the query to the other DS at all, and (b) whether it should
try to authenticate.

This is a new kind of question in the Internet space, it seems to me,
since the only protocol that commonly does referrals (or chaining,
equivalently) now is DNS, which is always unauthenticated.  For most
protocols authentication is either always done (eg POP, IMAP) or never
done (eg SMTP, DNS) so per-connection control isn't an issue.

We can all agree that these decisions have to be driven by policy; which
is to say by using the word "policy" we express the hope that this stuff
is configurable in a flexible way, and not set at compile time.  Policy
comes from lots of places: some does come compiled in to apps and to
libraries (even if only as defaults), some is set by end-users, some by
local admins, some by site admins, server admins, etc.  An evolved system
would let policy be expressed at any of these levels, with appropriate
UIs, sanity checks, auditing capabilities, etc.

I think Kurt and Paul are arguing about how the policy implementation
relates to the C API.  Should the C API implementation make reference to
the policy machinery under the covers, out of view of the app and the API,
or should it pop the questions up to the app, via the API, at every
decision point?  IMHO a well-formed app would just hand the questions off
to its policy implementation in any case, so the pictures don't really
look very different.  The practical question, perhaps, is whether it's
reasonable to modify the C API every time it's realized that some
operation should be subject to policy control.  I suspect not.

A more evolutionary approach would call out those operations most in need
of policy-oriented control.  Then a separate API to get/set these policy
settings could be developed, and could be used by apps to achieve the same
results they'd get via having the questions popped to them via the regular
LDAP API.

 - RL "Bob"