Subject: C LDAP API: security considerations

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 08 Nov 1999 20:46:08 -0800

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.

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

I also suggest that "long-lived" should be clarified. Something
like "implementations should not maintain copies of authentication
information, including credentials, any longer than necessary."
In particular, authentication information should not live longer
than the API call it was used with.  (Implementations are encouraged
to "forget" such information sooner).

Note also that I prefer "authentication information" over
"authentication credentials" as the authorization ID itself
may be sensitive.

Kurt

---

From: Ashish Kolli <[email-masked]>
Date: Tue, 9 Nov 1999 12:13:14 -0800 (PST)

Hi Kurt,

	Your suggestions are good but it is difficult to get
a consistent implementation unless one (or all) of the following are put
in the standards track:

- additional API hooks to control the referral chasing characteristics on
  the client side. Currently the API draft provides for functions/control
  that can chase or not chase referrals. We need some more controls that
  will allow a client to control the type of authentication used when
  binding to a referred server.
  
- Root DSE of the main LDAP server containing some information about the
   'trustworthiness' of LDAP servers that it can return referrals to.

- the 'trustworthiness' of the referred servers being returned with the
   actual referral message from the main LDAP server.

I would recommend against changing the current default behavior of clients
chasing referrals. I think that the clients should use the same
'authentication information' for the referred server as the main server.
This is useful because:
	+ it will cover most of the usage cases
	+ it requires no change to existing client code
	+ to some extent it requires little administrative overhead
	   (other than duplicating the user information in both the
	     LDAP servers)

Only the security minded clients should use the additional
API functions to hide the 'authentication information' from "unsafe"
servers while chasing referrals. 

Comments/suggestions are welcome.

Regards,

Ashish Kolli

OiD Group

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sat, 13 Nov 1999 12:37:11 -0800

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.

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

I also believe it wise to review the security considerations
of RFC2251 in the area of knowledge information trust.

Kurt

---

From: [email-masked] (Rob Weltman)
Date: Sat, 13 Nov 1999 13:00:08 -0800

> to utilize this mechanism, the API implementation should

  That is the behavior of the Java LDAP API (although I can't claim that I had thoroughly thought through the pros and cons of having the default behavior be to not follow referrals).

Rob