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

Re: anonymous binds

I've trimmed the CC list to LDAPbis to cut down on unnecessary
cross posting of LDAP revision discussions.

At 10:26 AM 11/14/00 -0700, Jim Sermersheim wrote:
>RFC 2251 seems to conflict itself when talking about anonymous binds. 
>
>In 4.2 the explanation of the name field says: "This field may take on a null value (a zero length string) for the purposes of anonymous binds" which at first glance seems to imply that an empty name signifies an anon bind.
>
>In 4.2.2, the wording is: "If no authentication is to be performed, then the simple authentication option MUST be chosen, and the password be of zero length, ... Typically the DN is also of zero length". This says (a bit more explicitly) that an empty (simple) password signifies an anonymous bind (I assume the intent was that no authentication is the same as anonymous bind).
>
>Questions:
>
>1) Is it the intent that "anonymous bind" and "no authentication" are equal here? If so, I propose we use the term anonymous bind in 4.2.2 to clarify.

I believe, in this context, these terms are synonymous (in
another context, no authentication might imply no bind request).


>2) Which signifies an anonymous bind, an empty name or empty simple password?

A simple bind with an empty password.   By my reading of 2251,
the DN should be empty and ignored if present.  However, for
security reasons, I believe this is bad.  I believe it appropriate
to say that the DN shall be empty and if not, invalidCredentials
returned.

>3) What does it mean to bind with an empty name and a simple password that contains data?

It means that you are attempting to authentication as the root DSE.


>Is there or will ther be a need to authenticate as the root DSE using simple authentication?

A server could treat such as authentication of some DSA-specific
service account.  I see no reason to disallow such (when appropriate
security protections are in place).

>If not, we should state that this case results in a protocolError.

I believe protocolError is inappropriate.   I believe success
(assuming password is empty or valid) or invalidCredentials
(if password is invalid) is a more appropriate result.

Kurt