[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: When to not deref aliases
Kurt,
If an alias dereferencing problem is detected when processing a bind,
invalidCredentials can be returned (the bind name is invalid). I guess you
were objecting to the lack of specificity. However, security errors are
meant to cover a multitude of sins as one doesn't want to give the enemy too
much information.
Ron.
-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, 24 January 2001 17:29
To: rvh@qsun.mt.att.com
Cc: JIMSE@novell.com; Ramsay, Ron; ietf-ldapbis@OpenLDAP.org
Subject: RE: When to not deref aliases
At 12:53 AM 1/24/01 -0500, Richard V Huber wrote:
>If aliases are not dereferenced for BINDs, what is the expected
>behavior when the dn of an alias is used as the argument to BIND?
invalidCredentials. The provided DN/password pair, which
together are the credentials, is invalid.
>As Thomas Salter noted in a previous posting, an alias entry will
>typically not have the UserPassword attribute needed for a simple BIND,
>nor would it have any other attributes that might be used as part of
>authentication.
I actually believe aliasing dereferencing in bind should be
disallowed as there bind cannot return aliasProblem or
aliasDereferencingProblem per RFC 2251. But "SHOULD NOT" is
enough.
>It seems to me that saying BIND SHOULD NOT or MUST NOT dereference
>aliases is pretty much the same as saying that BIND should never be
>used with an alias as its target dn.
Imperitives are to should be applied and interpreted as detailed
in RFC 2119.
>If this is our intent, let's say
>so explicitly (this would avoid some really messy access control
>issues). But let's not do it as a side effect.
I believe there are sufficient security considerations to
require a "SHOULD NOT".