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

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 13:25:34 -0800

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

---

From: "Howard Chu" <[email-masked]>
Date: Thu, 18 Nov 1999 13:49:24 -0800

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, [email-masked]
  Chief Architect, Symas Corp.