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

[Howard Chu <hyc@highlandsun.com>]

> -----Original Message-----
> From: Paul Leach (Exchange) [mailto: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.

OK, I guess I was reading more into your message than was justified...
>
> 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.
>
I guess. But without central management it's still a nightmare.

> 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.
>
If you want security to be a standard part of the API, and you want it to be
manageable, you do need to standardize the mechanism for retrieving the
policy.
That also implies that you've standardized where and how it is stored.

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

(1) is precisely the same as your 2nd paragraph above. Your disagreement
here doesn't make any sense to me.
> >
> > 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.
>
My suggestion was actually stronger than that - the server should be
responsible for the enforcement of policy, not just for storage of the
policy configuration.
As a specific example - if your policy is "no cleartext transactions of any
kind" then you turn off the standard LDAP port and only allow SSL/TLS
connections to the server. In absence of VPNs you may be more specific and
say "require TLS sessions on all connections from foreign subnets."

My suggestion for referral handling was a protocol change, where the
referral notification includes an indication of the trust level/minimum
required authentication level for the target of the referral. The main
motivation here is that only the directory admin really knows the
value/sensitivity of the information in a given server. If the admin allowed
her server to return referrals to other servers, again a value judgement had
to be made when deciding to store that referral node in the home server. I
am making an assumption here that in any environment, there will be a "home"
directory server that is trusted by everyone working in that environment,
and this server is the first stop for most lookup needs. This is, indeed, a
single server that tells you how much to trust any other servers that it may
refer you to.

Outside of that scope, I think the issue is irrelevant. An admin defining
security policy is really only responsible for protecting the integrity of
the data and directories that she administers. When a user connects to a
foreign directory for totally unrelated data, outside of the admin's scope
of responsibility, the local admin's policies should no longer apply.

For example, if I'm Joe Blow talking to my company's corporate directory
server, and in the course of a lookup I'm referred to some external server,
it's reasonable for me to *expect* that my subsequent authentications are
"safe". I.e., the local admin should not be referring local users to foreign
sites in an insecure manner, especially when the referrals are intended to
be invisible to the user.

But if I'm on my lunch break and just trying to connect to 411 or bigfoot to
look up my buddy's email address, this query is completely outside my local
admin's responsibility.

And of course, a site-wide policy that forbids plaintext passwords of any
kind may inadvertently prevent me from using certain public directories. Any
mechanism that brings in undesirable side-effects like this should be
avoided.

Finally - the client side of any client-server relation is almost always the
wrong place to be trying to enforce policy of any kind. Anyone can always
cobble up their own client to talk to a server however they wish. The only
place where it is possible to guarantee the enforcement of your policy is in
the server itself, by configuring it to reject any requests that don't
adhere to your policy.