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

Re: unauthenticated bind



Hallvard,
 
I've covered all of thesee points in the -09 draft to be published shortly.
 
Roger

>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 11/14/2003 12:54:25 PM >>>
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 a! n 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