Subject: RE: C LDAP API: security considerations

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Thu, 11 Nov 1999 16:03:24 -0800

> -----Original Message-----
> From: Harald Alvestrand [mailto:[email-masked]]
> Sent: Wednesday, November 10, 1999 8:06 AM
> To: Paul Leach (Exchange); Kurt D. Zeilenga
> Cc: [email-masked]
> Subject: RE: C LDAP API: security considerations
> 
> 
>> At 06:23 10.11.99 -0800, Paul Leach (Exchange) wrote:
>> But if the authentication is strong, there's no reason not to
automatically chase referrals.

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

Actually, when I said there was no reason to not chase the referrals, I
really meant there was no _security_ related reason to not chase them. 

Secondly, I'm not sure I completely understand the scenario. I see two
interpretations:

1. If the public directory is really public, then it should not require any
authentication. As such, I believe that the SASL negotiation, which
originates at the server, would tell the client not to bother doing any
authentication work. However, one of the experts in how LDAP auth works
should make sure I'm not in left field (i.e., completely wrong). And if it
doesn't work this way, it ought to  :-)

2. If the public directory requires authentication, and allows public key
authentication, and the problem you point out existed, it would be a denial
of service problem with the implementation of the public directory. And as
such wouldn't constitute an argument against doing authenticated referrals.
It might argue that we need a way to avoid such DOS attacks in LDAP itself,
in which case your comment about more work begin needed would be correct.

Paul

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 15 Nov 1999 01:39:52 -0800 (PST)

Paul Leach wrote:

> 1. If the public directory is really public, then it should not
> require any authentication. As such, I believe that the SASL
> negotiation, which originates at the server, would tell the client not
> to bother doing any authentication work. However, one of the experts
> in how LDAP auth works should make sure I'm not in left field (i.e.,
> completely wrong). And if it doesn't work this way, it ought to :-)

It's quite reasonable IMHO for a directory service to provide useful
responses to both unauthenticated and authenticated requests, eg to
provide more/different attributes/entries to a given request R when that
request is via an authenticated connection than it does to the same
request (ie, filter) when unauthenticated; whether such a directory is
"public" I will leave to the sophists.  In any case, I would think that
almost all directory services, even if designed to service unauthenticated
requests, would still provide administrative access via authenticated
LDAP; so the case of a DS that rejected any attempt to authenticate would
not likely occur in nature, it seems to me.

If a DS really didn't provide for authentication at all, then it would set
its supportedSASLMechanisms in its root DSE to the null set, and a client
could look this up before trying to authenticate.  Note that the cautious
client might try to authenticate anyway, since the mechanisms lookup might
have been tampered with on the wire.  In any case there is no similar
attribute, I think, to say that simple binds aren't supported (twould be
useful, though).

So, I think the idea that the server could convey "don't bother
authenticating" via SASL isn't true technically, and doesn't make much
sense to begin with.  In practice a client that for some reason thinks it
wants to authenticate to a server that isn't interested will find that any
SASL mechanism it proposes will be met with an error response; or that its
bind attempts all fail.  Whether it proceeds with an unauthenticated query
after that is obviously a matter of client policy.

 - RL "Bob"