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

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 1999 15:17:19 -0800

At 01:25 PM 11/18/99 -0800, Paul Leach (Exchange) wrote:
>Let me try and give a concrete example of how one might specify one policy
>in the LDAP API spec.

One policy?  As Bob Morgan pointed out, policy is not singular.

Just because an Directory Admin says so doesn't mean the a Directory
User must do so.  The Directory Admin may not have authority to
enforce information use policy upon the user.

Kurt

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 16:01:54 -0800

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 3:17 PM
> To: Paul Leach (Exchange)
> Cc: 'Harald Tveit Alvestrand'; Paul Leach (Exchange);
> [email-masked]
> Subject: Re: Policy in IETF APIs (was: Standards and APIs)
> 
> 

You are misreading that sentence.

It said it was an example of one policy, not an example of the only policy.

> enforce information use policy upon the user.

Who said anything about Directory Admin? The kind of admin I was talking
about is one who has authority over what the Directory User can do.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 1999 16:12:33 -0800

At 04:01 PM 11/18/99 -0800, Paul Leach (Exchange) wrote: 
> The kind of admin I was talking about is one who has authority
> over what the Directory User can do.

This may not be same admin who has authority over what information
is published by the Directories to which the user has been authorized
to obtain information from.  That is, one admin may have authority
over what information is published to the user and another admin
may have authority over how that information is used.  This
policy scenerio is quite common.

Kurt

---

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

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 4:13 PM

> policy scenerio is quite common.

So? The above observation, although correct, is not relevant to the proposal
I made.

It could even be a third admin who is worried about the security of their
site, and they're the one that gets to say that plaintext passwords are not
to be used by any user, Directory User or otherwise.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 18 Nov 1999 16:40:15 -0800

At 04:25 PM 11/18/99 -0800, Paul Leach (Exchange) wrote:
>So?

My point is that the LDAP API should be policy neutral.  The
API can and should provide mechanisms for application
developers can implement policy aware clients; however,
the API itself should not be policy aware.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 17:10:15 -0800

> Sent: Thursday, November 18, 1999 4:40 PM

> 
> My point is that the LDAP API should be policy neutral.
>  The API can and should provide mechanisms for application

First, the IESG long ago said that it isn't permissible to ignore security
any more. Leaving security policy enforcement to applications has proven
unworkable, and is not acceptable to the security community. So the LDAP API
can not be security policy neutral.

Second, the policies I proposed all could be configured to be null. I.e.,
plaintext passwords could be allowed, and all servers could be trusted. That
means that it can be configured to be "policy neutral".

Third, I'll agree with you that it ought to be able to use LDAP API to
implement the policy checking -- e.g., storing the configuration data that
drives policy. I'm happy with a flag that says "ignore policy" -- ideally,
it should only be usable from within the LDAP API implementation itself, but
I'd be willing to leave that as an implementation choice.

Paul

---

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

> From: Howard Chu [mailto:[email-masked]]
> Sent: Thursday, November 18, 1999 5:56 PM
> 
> > From: Paul Leach (Exchange) [mailto:[email-masked]]
> >
> > 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

---

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

> here doesn't make any sense to me.

Not quite the same. (1) talks about standardizing -- I agreed that one could
use the mechanism (of stroing the config in the directory), even if it isn't
standardized. One could also use other mechanisms, although storing it in
the directory has the advantages you noted.

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 18 Nov 1999 23:07:32 -0800

> From: Paul Leach (Exchange) 
> Sent: Thursday, November 18, 1999 8:13 PM
> 
> 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.

A clarification (dangling pronoun) -- the kind of policy I want the client
to handle is the policy that protects the users/clients against servers and
the network, not the servers protecting themselves from users/clients or the
network.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 19 Nov 1999 10:16:30 -0800

At 05:10 PM 11/18/99 -0800, Paul Leach (Exchange) wrote:
>any more.

I do not believe anyone participating in this discussion is
ignoring security.

I believe that the protocol and its APIs should be policy neutral,
at least at the lowest levels, to allow applications AND higher
level APIs to implement security policy enforcement.

The lower level LDAP API should be designed to have a causal
relationship with the protocol.  The low level API should
provide calls which map directly upon protocol elements.
Higher level API calls can then use these calls to implement
"synchronous" routines, multiple-step protocol exchanges,
and cross protocol session interactions (such as chasing
referrals).

I believe that current API specification is not well layered.
In particular, I believe that a LDAP session handle should only
represent a single protocol session (with a particular server)
and that a higher level construct be used to group multiple
protocol sessions.  API calls would then be defined to support
operations which interact between sessions within the constuct.
Low level calls with this construct should provide direct
application control of cross protocol session interactions.

However, I do not believe there is wide support for redesigning
the LDAP C API.

To improve API security within the existing draft it wise to
state that implementations should not perform operations (such
as chasing referrals) without application interaction.

"MUST be configurable" is, in my opinion, better left
to much higher level APIs.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Fri, 19 Nov 1999 12:57:38 -0800

> Sent: Friday, November 19, 1999 10:17 AM
> 

There would be NO CHANGE in the API. I proposed _implementation
requirements_ that are invisible to clients.

> as chasing referrals) without application interaction.

This does not improve security -- it sweeps the need for it under the rug.

> to much higher level APIs.

What you are saying is that security is to be left to (non-existent) upper
layers. That means it won't be secure. All experience in this area supports
that contention. One of the most elementary security rules is that security
can not be left to applications.

Paul

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sun, 21 Nov 1999 04:33:52 +0100

>can not be security policy neutral.

I think this is stretching the IESG position a bit.
The IESG policy is intended to insist that standards-implementing products 
must make it *possible* for protocols to implement sane security.
It's been hashed out very many times that it's impossible to require that 
they *use* that security.

I think the LDAP API would definitely be rejected for standards-track if it 
did not offer API functions to use adequate security mechanisms.

But this does not imply that the API should be a policy enforcement point.

                         Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Sun, 21 Nov 1999 17:47:27 -0800

> From: Harald Tveit Alvestrand [mailto:[email-masked]]
> Sent: Saturday, November 20, 1999 7:34 PM

> But this does not imply that the API should be a policy 

I wasn't trying to say that it had to be a policy enforcement point just
because of the IESG requirement that security be dealt with in standards.

I do believe that security considerations relevant to LDAP mandate that the
LDAP API be _able_ to be enforce certain policies related to those security
considerations.

Most particularly, IIRC, the continued use of plaintext passwords as an
authentication mechanism was the proximate cause of the IESG mandate to have
security considerations in new standards.

In that light, I think that my proposal to require implementations of the
LDAP API to be configured to not send plaintext passwords is fairly modest.
The proposal did not say that they have to enforce that policy -- it just
says they have to be configurable to enforce that policy. I.e., w.r.t. your
comments, it does not require that they use the security, only that users
concerned with security have the tools to get it.

Paul