RE: anonymous binds

["Volpers, Helmut" <helmut.volpers@icn.siemens.de>]

In our implementation we allow a bind with DN>0 and an empty password
and I will not change this because there are some applications
which does this kind of bind (e.g. for statistics).
We assign (like x.500) for every bind a AuthenticationLevel
which is "NONE" if you send no password (independant whether the DN
is empty or not and which is SIMPLE when you give a name and Password.
I agree with Mark that there is no real difference between 
an "unauthenticated bind" and an "anonymous bind."
Especially for AccessControl it is the same.

Helmut

> -----Original Message-----
> From: mcs@netscape.com [mailto:mcs@netscape.com]
> Sent: Mittwoch, 15. November 2000 21:46
> To: Jim Sermersheim
> Cc: Kurt@OpenLDAP.org; Richard Ellis; ietf-ldapbis@OpenLDAP.org
> Subject: Re: anonymous binds
> 
> 
> I am not convinced that there is any real difference between an 
> "unauthenticated bind" and an "anonymous bind."  Certainly in 
> terms of 
> access control and so on, they are likely equivalent.
> 
> Can someone provide a useful definition?
> 
> -Mark Smith
>   Netscape
> 
> 
> Jim Sermersheim wrote:
>  >
> 
> > I wonder how many implementations will be broken by stating that 
> > non-empty DN + empty PW != anonymous.
> > 
> >  >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/14/00 7:15:32 PM >>>
> > At 04:26 PM 11/14/00 -0500, Mark C Smith wrote:
> >  >No.  I am saying that I believe a > 0 length DN with an 
> empty password 
> > should be accepted as an anonymous bind.  I think Kurt was 
> suggesting 
> > that servers should return invalidCredentials instead if 
> the DN is of 
> > non-zero length..
> > 
> > RFC 1777 makes a distinction between unauthenticated and anonymous
> > bind.  That is, they are NOT synonymous.
> > 
> > I see the following four usages:
> > 
> >   DN            Password        Usage
> >   ------------------------------------------------------------
> >   empty empty           anonymous
> >   non-empty     empty           unauthenticated
> >   non-empty     non-empty       authentication
> >   empty non-empty       authentication *
> > 
> > We should not disallow any of these usages in the revised 
> specification.
> > However, we might want to clarify each usage and any usage-specific
> > security consideration.
> > 
> > Note that latter usage can be left unspecified as to what entity
> > is implied by the empty DN.  This could be a "self" authentication
> > (DSA authenticating to itself... some servers talk LDAP 
> with themselves)
> > or some special admin entity.   Leaving it unspecified allows for
> > such experimentation and, if ever desired, standard track extension
> > or update of such.
> > 
> > Kurt
>