Subject: RE: C LDAP API: security considerations

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Tue, 9 Nov 1999 13:46:27 -0800

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Monday, November 08, 1999 8:46 PM
> To: [email-masked]
> Subject: C LDAP API: security considerations
> 
> 
> I believe it wise to add a security consideration stating that
> implementations should not reuse authentication information,
> without application interaction, when chasing referrals.
> That is, unless the application authorizes reuse with the
> authentication information (or provides new information via
> some mechanism) with the server chased, the implementation
> should use an anonymous bind.

I disagree. This will just encourage making information available to
anonymous binds. Use of anonymous bind in thise scenario violates basic
security principles -- the request should be made under the appropriate
identity.

> 
> Even if DIGEST-MD5 was in use, such application interaction
> should still be recommended to be consistent with "keeping
> long-lived copies of credentials without the application's
> knowledge is discouraged."

The application does have knowledge. It's the one providing the credentials
for the referral.

Your underlying point is valid. Applications should be careful when keeping
creds or cred-like info around. In fact, they really need to entrust such
info to the OS, which can keep it encrypted in a non-pageable place. But, if
proper precautions are taken, there is no reason that the referral should
not be made using correct, authenticated, identity.

Paul

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 10 Nov 1999 05:36:35 -0800

My primary concern is that an API should not chase referrals
without application interaction when doing so might expose the
credentials unexpectedly.  If the authentication mechanism,
such as DIGEST-MD5, adequately protects the credentials, then
I see little problem with allowing the authentication without
per-chased referral bind.  However, if the authentication
mechanism is simple or such, then I believe it unwise to reuse
credentials while automatically chasing referrals.

Most current SDKs, I believe, will not reuse authentication
credentials specified with a simple bind when chasing referrals.
Instead, they bind anonymously or utilize some application
interaction mechanism to obtain new credentials.   I believe
we should encourage such behavior.

Kurt

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

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Wed, 10 Nov 1999 06:23:26 -0800

If you don't trust the directory you are querying to not refer you to a
dangerous place, why should you trust any other data it returns to you?

I'll agree with your recommendation as long as it is qualified as you do --
the concern is primarily over the use of weakly protected credentials (which
should be strongly discouraged anyway!). But if the authentication is
strong, there's no reason not to automatcially chase referrals.

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Wednesday, November 10, 1999 5:37 AM
> To: Paul Leach (Exchange)
> Cc: Kurt D. Zeilenga; [email-masked]
> Subject: RE: C LDAP API: security considerations
> 
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 10 Nov 1999 11:06:10 -0500

At 06:23 10.11.99 -0800, Paul Leach (Exchange) wrote:

>I'll agree with your recommendation as long as it is qualified as you do 
>-- the concern is primarily over the use of weakly protected credentials 
>(which should be strongly discouraged anyway!). But if the authentication 
>is strong, there's no reason not to automatcially chase referrals.
Chasing referrals will probably take a while.
Consider that if you're using an RSA-based mechanism for authentication, 
and the referral is to a public directory, the failed login step will 
consume a significant number of CPU-seconds.

More work needed?

                      Harald

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 14 Nov 1999 08:59:34 -0800

At 11:03 PM 11/13/99 -0800, Paul Leach (Exchange) wrote:
>Suggest one plausible way in which it is possible to specify policy to an
>application to do anything with the flexibility you insist must be present.

I believe such should be considered outside the scope of the particular
API specifications.  I believe this issue should be addressed by
extensions to the protocol and/or information model.  These extensions
may mandate how API should chase referrals.  However, until such
extensions are drafted, I believe it inappropriate for the API
specification to mandate a policy not defined by the protocol and/or
information model.

>I.e., suppose the application is informed that it has been given a referral.
>When and how will it decide to chase it, and when not?

Currently unspecified.

>Applications have no idea how to answer the above question. Neither do
>users.

The current protocol/information model relies on implicit policy agreements between users and the directory.  The API implementation has no knowledge
of these policy agreeements. 

>If there were to be a mechanism to answer that question, and a way to
>specify the policy for answering it, they should be _below_ the level of the
>LDAP API, so that use of the mechanism and enforcement of the policy would
>_not_ depend on all the applications doing the right thing, since experience
>suggests that will never happen.

I believe that client APIs are the tools for client applications to
implement policy from their, the user's, perspective.  It my view
that APIs should provide control/flexibility over policy enforcement
to the application (and it to the user).

Kurt

---

From: Bruce Greenblatt <[email-masked]>
Date: Sun, 14 Nov 1999 19:02:21 -0800

I agree completely with Paul!

At 11:03 PM 11/13/99 -0800, Paul Leach (Exchange) wrote:
>users. If there were to be a mechanism to answer that question, and a way to
>> Sent: Saturday, November 13, 1999 12:37 PM
>> Subject: Re: C LDAP API: security considerations
>> 
>> 
>> After some additional thought on this matter, I believe it
>> inappropriate of API implementations to chase referrals without
>> application interaction.  An API implementations should
>> not assume the application's trust in the server providing
>> the knowledge information extends to the referenced server.
>
>Why? If the application trusts the first server to give correct answers, why
>shouldn't it trust the servers to which it gives referrals?
>
>> 
>> A client application should be in direct control of which
>> servers it does or doesn't connect to.  A client application
>> should be in direct control of which request are submitted
>> to servers.  A client application should be in direct control
>> of which information is provided with each request.
>> 
>> I suggest that the default behavior of API implementations
>> should be to NOT chase referrals.  I suggest we extend
>> the API specification to provide a mechanism to allow
>> applications that wish to progress the operation to do so
>> under the application's control.  If the application fails
>> to utilize this mechanism, the API implementation should
>> not chase the referral.
>
>I suggest that the default should be to chase referrals, and that an
>application which is worried about chasing referrals should have a way to
>opt out by providing a mechanism such as you suggest.
>
>If referral chasing is not easy for applications, it won't usually be done.
>
>If referral chasing is not usually done, then the freedom of a server to
>partition its NC onto several servers with referrals to bridge them will be
>eliminated.
>
>> 
>> I also suggest that we then add a security consideration
>> to the C LDAP API I-D that encourages applications to
>> interact with users to determine if chasing is appropriate.
>
>Nonsense. Users always say "yes".
>
>Paul
>
>
>
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 15 Nov 1999 16:48:59 -0500

>When and how will it decide to chase it, and when not?

One plausible way, modelled on IE5's "server zones":

The UI stores a list of all servers encountered during searchs or referrals.
By default, all servers are listed in the "anonymous" zone, the UI chases 
referrals to these, and gives no authentication data.

For servers in the "internal" zone, which can be all server names matching 
"domain", or explicitly enumerated, the UI chases referrals, and uses RSA 
authentication with the company certificate.

For servers in the "expensive" zone, the UI will pop up a dialog box before 
chasing a referral.

Elaborate until user confused :-)

Note: These are *exactly* the kinds of considerations that lead to popup 
boxes today when chasing links between HTTP and HTTPS pages.
What makes sense in HTTP can't be called totally meaningless in LDAP.

                           Harald

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 15 Nov 1999 09:13:54 -0800

> From: Harald Tveit Alvestrand [mailto:[email-masked]]
> Sent: Monday, November 15, 1999 1:49 PM
> 

You propose a fine mechanism.

I would note that it is _not_ implemented in IE. It is implemented _below_
the WinInet API, which is the layer that IE, and lots of other apps, use to
do HTTP. I.e., it is the moral equivalent of the LDAP API.

> For servers in the "expensive" zone, the UI will pop up a 

I would note that one can't rely on any client-side mechanism to prevent
denial-of-service attacks on the server, if that was your intent. In
particular, the "expensive" zone won't prevent malicious clients from
bogging down LDAP servers with public key operations. For non-malicious
clients, the 20ms or so of CPU it costs for the public key operations is not
likely to be a big deal worth annoying the user about. (Whereas it is a big
deal to limit servers to the 50-100 requests per second that such a CPU cost
implies.)

Paul

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Tue, 16 Nov 1999 12:16:43 -0800

> Sent: Tuesday, November 16, 1999 1:58 AM
> 
> My concern is that a client should be *able* to behave in a 
> way that is 
> both non-malicious and secure; at the moment I don't think 
> we're ready to 
> standardize this, so following referrals should be done above 
> the API layer 
> that we're currently attempting to standardize.

Fine -- then let's make an _option_ that says "I'm a really smart app, and I
want to have control over whether referrals are chased".

However, I still believe that apps don't want to be that smart, that no apps
are that smart, that no apps should be expected to be that smart, and that
no apps can be that smart.

In particular, with respect to the last point, any policy that an admin
wants to apply, they want to apply across all the apps in their
organization. E.g., if Dun&Bradstreet is an "expensive" site, then all apps
should avoid it if the policy is not to pay. Or, conversely, the policy
might be that only fee-based sites with which the organization has an
agreement can be used -- in which case, again, _all_ apps should obey the
policy. IMO, the only way that can happen is if the LDAP API layer does it.
It is not plausible that lots of independently developed apps will enforce
such policies in the same way. That's what I meant by "no apps can be that
smart" -- they can't be the same as other apps.

FInally, all these requirements for public directories are conflicting with
what often wants to happen within an organization. Organizations will want
the ability to repartition their namespace across servers without affecting
the clients. This implies that referrals get chased automatically.

Paul

---

From: "Anoop Anantha (Exchange)" <[email-masked]>
Date: Tue, 16 Nov 1999 11:05:39 -0800

Having applications manually chase referrals on a case by case basis
involves quite a bit of extra code on the app's part and may discourage
people from writing to this LDAP API.

How about Kurt's initial suggestion of discouraging rebinding when clear
text credentials are used? This would prompt apps to use strong auth in
general and would also solve this particular security problem.

Anoop Anantha

-----Original Message-----
From: Mark Smith [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 6:42 AM
To: Harald Tveit Alvestrand
Cc: Paul Leach (Exchange); [email-masked]
Subject: Re: C LDAP API: security considerations

Harald Tveit Alvestrand wrote:
> ...
> My concern is that a client should be *able* to behave in a way that is
> both non-malicious and secure; at the moment I don't think we're ready to
> standardize this, so following referrals should be done above the API
layer
> that we're currently attempting to standardize.

This argues for removing all references to "automatic" referral chasing
from the C LDAP API draft.  As others have pointed out, automatic
referral chasing is under specified at present, so removing  it is a
sane thing to do.  But most clients would like an automatic option, so
if we do remove it we should tackle it in a subsequent document.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Nov 1999 16:27:21 -0800

>general and would also solve this particular security problem.

I'm now thinking that even this is unwise.  If my public server
sends me to a "root" server and that "root" server sends me
to foo server... I may not want to expose myself to foo.

I am thinking that apps wanting anonymous auto chasing should
be able to just enable some LDAP_OPT_.  But the default being
the most conservative and not chase.

Kurt

----

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Wed, 17 Nov 1999 02:17:58 -0800

> Sent: Wednesday, November 17, 1999 5:23 AM

> 
> <SPAN MODE="IETF Policy">
> IMNSHO, this is exactly the wrong thing to have happen in the 
> *standard* 
> LDAP API. Policy engines cannot be standardized at the 
> present stage of our 
> ignorance; a standard API should (IMNSHO) be no more than a means of 
> creating protocol elements on the wire and state in the state 
> machines on 
> each end.
> 
> It is then up to the vendor (hi vendor!) to provide extended 
> APIs that 
> build upon the standard LDAP API to encapsulate policy 
> decisions by the 
> site admin.
> But this functionality SHOULD NOT be standardized and MUST 
> NOT be mandatory.
> </SPAN>

I respectfully submit that this is not why most people want a standardized
API. What you propose means that the LDAP API becomes an interface for
vendors to use to build the _actual_ API layer that applications call. That
layer would not be a standard. What people want is a standard API for
applications to use, not vendors.

I do not believe that it is necessary to have a standardized policy engine
to say that an API is supposed to enforce policy (whatever it is). That's
different than saying the API must enforce some particular policy.

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Wed, 17 Nov 1999 02:46:31 -0800

Ulp. There are too many considerations going on simultanously....
1. What creds to use to chase referrals -- some are weak, some cost the
target too much CPU (public key)
2. What should one do if the target charges money for a search (e.g.)
3. What's the LDAP API for, anyway.

I'm only going to address #1 in this message.

> 
> IF one implements the current spec as "simple credentials are 
> reused", the 
> result is that the right to write an operational entry 
> causing a referral 
> is now equivalent to the right to capture all passwords used 
> in LDAP with 
> referrral-chasing applications.

I'm _not_ in favor of that. (If it were up to me, simple creds would just be
MUST NOT all the time and this wouldn't be such an issue.)

For this aspect of the problem I think we can figure out what the default
Right Thing is. Here's a stab at it:

Security considerations dictate that referrals should be chased either
anonymously, or with strong authentication protocols. (A strong
authentication protocol is one that it is safe to use even to a hostile
server or in the presence of eavesdroppers or active attackers.)

In that model, a client would use strong auth when chasing a referral if the
server supports strong auth, otherwise chase it anonymously.

I don't think this has security issues, although the other considerations
may weigh upon it.

Paul

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 17 Nov 1999 08:22:36 -0500

At 12:16 16.11.99 -0800, Paul Leach (Exchange) wrote:

>Fine -- then let's make an _option_ that says "I'm a really smart app, and 
>I want to have control over whether referrals are chased".

We already have that.
The question is whether we remove it, mandate one reasonable thing to do 
with credentials when chasing referrals, or add more controls to let the 
client control what the Right Thing is.

>However, I still believe that apps don't want to be that smart, that no 
>apps are that smart, that no apps should be expected to be that smart, and 
>that no apps can be that smart.

My take is that not doing this right is forcing applications to be stupid 
whether they want to or not.

IF one implements the current spec as "simple credentials are reused", the 
result is that the right to write an operational entry causing a referral 
is now equivalent to the right to capture all passwords used in LDAP with 
referrral-chasing applications.

May be a valid policy decision. But it needs to be an informed one.

>organization. E.g., if Dun&Bradstreet is an "expensive" site, then all 
>apps should avoid it if the policy is not to pay. Or, conversely, the 
>policy might be that only fee-based sites with which the organization has 
>an agreement can be used -- in which case, again, _all_ apps should obey 
>the policy. IMO, the only way that can happen is if the LDAP API layer 
>does it. It is not plausible that lots of independently developed apps 
>will enforce such policies in the same way. That's what I meant by "no 
>apps can be that smart" -- they can't be the same as other apps.

<SPAN MODE="IETF Policy">
IMNSHO, this is exactly the wrong thing to have happen in the *standard* 
LDAP API. Policy engines cannot be standardized at the present stage of our 
ignorance; a standard API should (IMNSHO) be no more than a means of 
creating protocol elements on the wire and state in the state machines on 
each end.

It is then up to the vendor (hi vendor!) to provide extended APIs that 
build upon the standard LDAP API to encapsulate policy decisions by the 
site admin.
But this functionality SHOULD NOT be standardized and MUST NOT be mandatory.
</SPAN>

>FInally, all these requirements for public directories are conflicting 
>with what often wants to happen within an organization. Organizations will 
>want the ability to repartition their namespace across servers without 
>affecting the clients. This implies that referrals get chased automatically.

Using what credentials?

                      Harald