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

Re: unauthenticated bind



Roger Harrison writes:
> 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.

Why forbid the SASL method ANONYMOUS (draft-ietf-sasl-anon-02.txt)?

Besides, as I mentioned in my authmeth-07 issues message, I think it is
better to avoid the MUST by formulating this as

  A client can explicitly establish an anonymous association
  by sending a Bind Request with a zero length password.

> Typically the name is also of zero length.

Drop this, it's implied by the SHOULD below.

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

..."instead of a Simple Bind with a password".

> in Section 10 (security considerations):
> 
> 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.

s/anonymous bind/unauthenticated bind/.  Unless you revise the suggested
definition of anonymous binds in 6.1 to say that an unauthenticated bind
is one kind of 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.

Move "with an error of invalidCredentials" to 6.1.  And maybe reword the
rest to 'This is why servers should by default reject...', since the
SHOULD has already been stated in 6.1.

-- 
Hallvard