Policy in IETF APIs (was: Standards and APIs)

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

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