> -----Original Message-----
> From: Howard Chu [mailto:hyc@highlandsun.com]
> Sent: Thursday, November 18, 1999 5:56 PM
>
> > -----Original Message-----
> > From: Paul Leach (Exchange) [mailto:paulle@Exchange.Microsoft.com]
> >
> > 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.
The only thing that needs to be standardized in the API spec is the behavior. A different spec can define a standardized centralized admin mechanism. In the absence of such a spec, a good, managable, LDAP API implementation will use a non-standardized centralized admin mechanism -- that means the admin cost grows linearly with the number of LDAP API implementations. That is still much much better that having it grow with the number of apps times the number of client machines, which is what other people are proposing. And also better than the number of implementations times the number of client machines, which is what happens if it isn't centralized.
Of course, a standard for how to store the configuration and how to access it would reduce the cost even further. As I said, there are WGs in the IETF working on that. We just don't need to, and shouldn't, depend on them.
>
> > 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.
Not quite the same. (1) talks about standardizing -- I agreed that one can use the mechanism, even if it isn't standardized.
> > >
> > > 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."
That doesn't work. A malicious server that is trying to collect plaintext passwords won't do this. The cllient has to protect itself.
>
> 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.
Some problems are amenable to this approach, some aren't. The problem is what to do might vary depending on who the user is. Some users are willing to connect to "for-fee" servers, some aren't. Admins should always connect with encrypted sessions, ordinary users don't need to. And so on.
Also, it requires a protocol change.
>
> 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.
That's true for directory admins. But the security admin for an organization is responsible for protecting the users from malicious servers and eavesdroppers and lots of other things. And IETF application protocol standards have to allow the security admins to do their jobs, not just the admins for the applications.
>
> Finally - the client side of any client-server relation is
> almost always the
> wrong place to be trying to enforce policy of any kind.
The only kind of policy that should and must be handled at the client is policy that protects the client against servers and the network. Servers can and should protect themselves. That's the only kind of policy I'm advocating having the LDAP API implementation handle.
I say "handle" because "enforce" is too strong a word -- since it's job is to protect the user, we assume that the user will cooperate in seeing that the policy is carried out. As you correctly point out, a user that wants to circumvent the policy will almost always be able to do so. They can use a plaintext password in violation of policy -- they can also post their password on a yellow sticky on their monitor. But we can and should deprecate both behaviors and make them go out of their way to do so.
Paul
Paul