RE: Policy in IETF APIs (was: Standards and APIs)

["Paul Leach (Exchange)" <paulle@Exchange.Microsoft.com>]

> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com]
> Sent: Thursday, November 18, 1999 1:49 PM
> 
> 
> This is interesting, but impractical in the real world. You 
> want a globally
> enforced configuration that the admin can set once and then 
> never have to
> think about again.

That would be nice, but I know that it's hard, and it wasn't what I had in
mind.

I quite deliberately said that policy was to be implemented "by means
outside the scope of this specification". I then went on to suggest it would
be good if an admin could set it without end user involvement. I didn't say
that it had to be done in a central place -- it may have to be done on each
client machine. I didn't even say that it had to be done just once per
machine -- in the worst case, it might even have to be done once for each
implementation of the LDAP API used on the machine. That's still better than
having it be done once for each application that uses the LDAP API on a
machine.

But I think that the use of DLLs on most systems these days means that the
system vendor can provide an implementation of the LDAP API, and hence
config data typically need be set only once per machine. Your suggestion
(below) that the config data can be obtained from an LDAP server then
enables the admin to set the config in just one place where it can be picked
up by all the clients who point to that configuration distribution point.
Thus making it practical in the real world.

I will stress that none of the above needs to be standardized as part of the
LDAP API spec. If standards for it eventually do get created, it will make
administration easier, but it is not required in order to meet the proposed
LDAP API security requirements or other policy requirements.

In the meantime, I think this is a good "divide and conquer" stategy -- we
can make progress on the LDAP API, we don't burden apps with problems that
they shouldn't have to be dealing with, we let progress happen on policy
standardization, and yet we get policy enforcement.

More comments below.

> Two problems:
>   1) you can't even standardize what that global config 
> mechanism is. By not
> specifying it in the API spec, you leave it up to each API 
> implementor, and
> so for an admin to secure a particular machine he has to know 
> how to perform
> this configuration for every possible API implementation 
> that's likely to be
> used on that machine.
>   2) a global configuration mechanism in the API is too 
> draconian. There
> will be plenty of times where someone has setup a sandbox 
> LDAP server, or
> some other local, innocuous server, where plaintext passwords 
> are perfectly
> acceptable. A globally enforced API configuration would 
> require the user to
> generate a full strong authentication infrastructure just to 
> be able to use
> this otherwise harmless sandbox.

I think these are false alternatives. See the next comment.
> 
> That's why I suggested that the best place to implement this 
> configuration
> is in the LDAP servers themselves.
>   1) For locally controlled servers of interest, the server 
> admin can set
> policy in a single place and it will be enforced no matter 
> whose API is used
> in the client.
>   2) For referrals from locally administered servers to 
> remote servers,
> again the admin can define a policy that is relayed in the 
> referral result
> itself. The local server admin is in the best position to 
> decide whether or
> not that target of a server can be trusted in particular 
> ways, or whether or
> not the remote server is "expensive."
>   3) For servers that are not locally controlled, that users 
> connect to
> directly, their fate is in their own hands. If they decide to 
> trust a remote
> server, that's their decision.

Using an LDAP server to store policy is a fine idea. There's even an IETF WG
working on exactly that.

But I don't see any conflict between that and saying that an LDAP API
implementation should read the stored policy and check that it has been met.

> 
> You are absolutely correct that it is unacceptable to leave 
> these policy
> decisions up to individual applications. Leaving it to particular API
> implementations is no better. The only place where you have 
> consistently
> guaranteed control over the situation is in the server itself.

Anything that can be controlled by the server is indeed better left on the
server. However, I don't think that covers all the necessary cases. I can't
depend on a server to tell me whether to trust it, for example. (I might be
able to depend on some _other_ server to tell me which servers to trust, but
that's not your model, as far as I can tell.) And I can't depend on a server
to tell me whether I ever send plaintext passwords -- the requirement is
cross-server.

Paul