[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: unauthenticated bind



Here's my proposal:

in Section 6.1 (Anonymous Authentication)

"An LDAP client may also explicitly establish an anonymous association.
A client that wishes to do so MUST choose the simple authentication
option in the Bind Request and set the password to be of zero length.
Typically the name is also of zero length. A bind request where both the
name and password are of zero length is said to be an anonymous bind. A
bind request where the name, a DN, is of non-zero length, and the
password is of zero length is said to be an unauthenticated bind. Both
variations produce an anonymous association. 

"Unauthenticated binds can have significant security issues (see
section 10). Servers SHOULD by default reject unauthenticated bind
requests, and clients may need to actively detect situations where they
would make an unauthenticated bind request."

in Section 10 (security considerations):

"Operational experience shows that clients can (and frequently do)
misuse unauthenticated bind (see section 6.1).  For example, a client
program might make a decision to grant access to non-directory
information on the basis of completing a successful bind operation. Some
LDAP server implementations will return a success response to an
unauthenticated bind thus leaving the client with the impression that
the server has successfully authenticated the identity represented by
the user name, when in reality, the server has simply performed an
anonymous bind.  For this reason, servers SHOULD by default reject
authentication requests that have a DN with an empty password with an
error of invalidCredentials. Clients that use the results from a simple
bind operation to make authorization decisions should actively detect
unauthenticated bind requests (via the empty password value) and react
appropriately."

Roger

>>> "Mark Smith" <markcsmithwork@aol.com> 11/12/2003 11:00:31 AM >>>
Jim Sermersheim wrote on 11/12/2003, 10:27 AM: 
Disallowing them completely may break some current client and server
implementations. I remember some people (maybe Mark Smith) from Netscape
saying that they use the mechanism as some way of voluntary auditing or
some such.
Yes, people do use it that way... I am not saying this is a great LDAP
feature from a security point of view though.

I prefer the compromise solution brought up in yesterday's meeting
where part of the note is moved into the main body of the document with
a pointer to the security considerations which contains the reasons
why.
That sounds OK although I'll have to see the exact proposal.

-Mark