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

[Howard Chu <hyc@highlandsun.com>]

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

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.

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.
  -- Howard Chu, hyc@symas.com
  Chief Architect, Symas Corp.

> Let me try and give a concrete example of how one might specify one policy
> in the LDAP API spec.
>
> Plaintext passwords.
>
> I hope we all agree that in some environments it's a Very Bad Thing to let
> plaintext passwords out. Exposure of the password on the wire completely
> destroys a site's security if eavesdropping is a significant
> threat in that
> site's environment.
>
> Hence it is very very important that a site be able to use of ban
> plaintext
> passwords in LDAP.
>
> In this context, it is totally unacceptable that the decision
> whether or not
> to send plaintext passwords is left up to the applications. Every single
> application at least has to be configurable to not send them. However, if
> there are dozens of LDAP-enabled applications, this is in practice
> unworkable. Especially if the configuration has to be done by end users.
> Hence, it is necessary that an implementation of the LDAP API handle
> enforcement of this policy.
>
> On the other hand, as Harald has pointer out, there is no standard policy
> engine, or configuration mechanism, or anything much at all in this area.
> That makes this tricky.
>
> How then, could we proceed?
>
> I would think something along the following line could be put into the
> specification:
>
> "An LDAP API implementation MUST, by means outside the scope of this
> specification, be configurable to never utilize plaintext passwords. It is
> RECOMMENDED that such configuration be able to be done by administrators
> without end user involvement."
>
> I think that security considerations in fact mandate such a
> requirement _of
> the LDAP API implementation_, not allowing it to be left to
> applications to
> do correctly.
>
> Similarly, when using TLS to secure a connection, passwords are protected
> against eavesdroppers, byt it is still bad to send passwords to
> servers that
> you don't trust. Hence, I think security considerations also mandate
> something like:
>
> "An LDAP API implementation MUST, by means outside the scope of this
> specification, be configurable to only send plaintext passwords to trusted
> servers, even over connections that are privacy protected (such
> as by using
> TLS). It is RECOMMENDED that such configuration be able to be done by
> administrators without end user involvement."
>
> The above style can be extended to tackle other problems, such as Harald's
> example of wishing to control chasing "expensive" referrals --
> ones to sites
> that charge for access. E.g.,
>
> "An LDAP API implementation MUST, by means outside the scope of this
> specification, be configurable to control to which servers clients are
> allowed to connect. It is RECOMMENDED that such configuration be
> able to be
> done by administrators without end user involvement."
>
> (Of course, for all of the above cases, the rationale for the requirement
> should also be spelled out if the requirements were to actually be
> incorporated into the spec.)
>
> NOte that the last proposed requirement would take care of both the
> "expensive referrals" problem and the "plaintext passwords to untrusted
> servers" problem.
>
> So, I don't think we need to have standard policy engines or
> other machinery
> in order to say what LDAP API implementations have to do.
>
> Paul
>
>
>
>