RE: C LDAP API: security considerations

[RL 'Bob' Morgan <rlmorgan@cac.washington.edu>]

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

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"