|
There may be applications where certian identities are allowed
to bind without a password (unatuhenticated bind) and access or modify certain
elements of the DIT (perhaps only on their own object), along with this, the
server may allow only one connection using that identity to happen at a time (no
worky in a distributed environment).
If we maintain that there is such a thing as an anonymous
bind, and there is also such a thing as an unauthenticated bind, but that the
semantics of each are implementation specific (as I believe the is case today),
will it cause problems? If we could spin it in such a way that a server decides
how similar or dissimilar the two binds are, could we keep the two notions
around? I'd simply like to preserve the original intentions while clarifying,
without breaking implementations.
Jim
>>> Mark C Smith <mcs@netscape.com> 11/15/00 1:45:33 PM >>> 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 |