Subject: RE: When to not deref aliases

From: "Jim Sermersheim" <[email-masked]>
Date: Fri, 12 Jan 2001 10:08:25 -0700

So it sounds like we should state that Compare and ModDN do not deref the alias. Does X.500 deref the bind name (or equiv) if it's an alias?

Jim

>>> "Ramsay, Ron" <[email-masked]> 11/16/00 7:24:03 PM >>>
You're right, Compare should not dereference (as it has no way of saying not
to dereference).

As regards X.500, CommonArguments, ServiceControls contains
options:dontDereferenceAliases, and this is available to all operations
(where Bind is not an operation). Of course, it is ignored in update
operations.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]] 
Sent: Friday, 17 November 2000 13:05
To: Jim Sermersheim
Cc: [email-masked]; [email-masked] 
Subject: RE: When to not deref aliases

At 06:39 PM 11/16/00 -0700, Jim Sermersheim wrote:
>Well, I don't think we can do that for v3. I'm just trying to get
clarification on whether we should explicitly state that alias dereferencing
does not happen for those three op's.

I assume this is in X.500 somewhere, but I believe aliases
should be dereferenced during processing of the search operation.
Other operations should act upon the alias, not the aliased object.

---

From: "Timothy Hahn" <[email-masked]>
Date: Tue, 16 Jan 2001 22:57:42 -0500

Kurt,

I agree with you that in absence of a control or parameter to specify what 
to do about alias dereferencing, that aliases are NOT dereferenced.

I think the 2251bis work should state this.

Regards,
Tim Hahn

Internet: [email-masked]
Internal: Timothy Hahn/Endicott/IBM@IBMUS or IBMUSM00(HAHNT)
phone: 607.752.6388     tie-line: 8/852.6388
fax: 607.752.3681

Sent by:        [email-masked]
To:     "Jim Sermersheim" <[email-masked]>
cc:     <[email-masked]>, <[email-masked]> 
Subject:        RE: When to not deref aliases

At 09:02 AM 1/16/01 -0700, Jim Sermersheim wrote:
>I don't think it's it's implied across the board.
>It's explicit for some operations.

Which is why I believe dereferencing is disallowed otherwise...

However, I agree that both interpretations are reasonable and
we need to got down to one interpretation.

When choosing one over the other, besides looking at the
technical merits of each, we should consider which interpretations
have been implemented and demonstrated interoperability.

In this case, I believe that aliases should not be dereferenced
in absence of a operation field (or control) specify the behavior
is a reasonable interpretation, a sound technical approach, is
widely implemented, and has demonstrated interoperability.

Kurt

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 17 Jan 2001 16:58:23 +1100

Kurt,

I may be going out on a limb here, but I think dontDereferenceAliases was in
ServiceControls.options in the 1988 version.

I note that bind is ambiguous.

No, we don't dereference aliases on update operations. There is a note in
the standard (from the 1988 standard, I think) that aliases should not be
dereferenced on update operations. (Apparently the latest standard has a
flag for overruling this behaviour.)

If you have a problem dereferencing an alias on a bind, I would think the
error should be securityError:invalidCredentials.

Does 'the distinguished name of an object' mean 'the distinguished name of
an entry'? An alias is an entry. I don't know if it is an object, but I
thought objects were phased out in favour of entries (aliasedObjectName?).

As regards LDAPv2, I was replying to your request regarding X.511. I know
LDAP is different (aliases, distribution, replication, read, list, ...). If
LDAP doesn't want to dereference on bind I won't cry. (I think vendors will
continue to do what they think is appropriate, anyway.)

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Wednesday, 17 January 2001 14:43
To: Ramsay, Ron
Cc: Jim Sermersheim; [email-masked]
Subject: RE: When to not deref aliases

At 12:39 PM 1/17/01 +1100, Ramsay, Ron wrote:
>I believe that dereferencing is the default for X.500.

>I say this because I
>believe the option dontDereferenceAliases was added to allow management of
>the alias entry itself.

I believe it the option was added when support for deferencing
alias in update operations was added (in the 2nd edition).  Note
that the option was not added to bind, hence I don't believe
aliases are to be dereferenced during bind operations.

>If the default were never to dereference, I would
>have expected the option to be dereferenceAliases.

Additional alias functionality was added to the second addition,
along with statements noting were the behavior could not be
expected by older DSAs.  Note that the bind operation, unlike
update operations, does not contain such a note.

>As regards the bind, we always dereference aliases.

Do you dereference aliases for add, compare, modify, moddn, or delete?
For bind, if you have an alias problem or dereferencing problem,
what result code do you return?

>You gain the ability to
>allow multiple logins (for access control) for the one user, though we
>haven't used this feature in practice.

You also incur numerous security risks.  I note that if the
consensus is to allow/require bind to dereference aliases, the
security considerations would have to be documented.

>If you don't take the default as being dereference, it seems you are saying
>that alias entries are second-class entries.

I thought they were.  :-)  They certainly were in LDAPv2 and
the first edition of X.500.

Note that X.511(93) says:
  If simple is used, it consists of a name (always the distinguished name of
an object),
  an optional validity, and an optional password.

IMO, X.511 nor LDAP allows binding to an alias name.

Kurt

---

From: "Salter, Thomas A" <[email-masked]>
Date: Wed, 17 Jan 2001 09:44:23 -0500

I have just checked various X.500 standards and reached these conclusions:

1. dontDereferenceAliases was in the 1988 version.  A note there says it
does not apply to operations which modify an entry -- they are never
dereferenced.

2. In the 1993 and 1997 standards there is a note on each of Add, Modify,
Remove, and ModifyDN that dontDereferenceAliases is ignored and assumed to
be set.

3. The 1997 standards also add an useAliasOnUpdate critical extension to
allow the modifying operations to dereference aliases.

4. dontDereferenceAliases is honored by Read, List, Search and Compare, with
the default being to dereference.

5. Aliases are not directly mentioned in the context of a Bind operation,
but X.509 states that a simple bind password is validated using the Compare
operation to test the UserPassword attribute.  There is no mention of
disallowing alias derferencing.

In summary, the X.500 defaults are that operations which read the directory
dereference aliases and those that modify the directory operate on the alias
entry itself.

---

From: "Volpers, Helmut" <[email-masked]>
Date: Thu, 18 Jan 2001 15:12:46 +0100

I agree totally with Kurt.

> Sent: Mittwoch, 17. Januar 2001 19:00
> To: Jim Sermersheim
> Cc: [email-masked]; [email-masked]
> I think that both RFC 2251 and X.511 are fairly clear
> in regards to update operations.  I think the only
> real issue is whether bind MUST, MUST NOT, SHOULD,
> SHOULD NOT, MAY or MAY NOT do aliasing dereferencing.
> 
> I would suggest "SHOULD NOT" as it this does not disallow
> an implementation from doing so, but makes it clear that
> dereferencing is not expected behavior.

I think X.500 is here a little bit stronger it explicitly
disallow the dereferencing in a Simple Bind. 
Dereferencing should not be the expected behavior.

Helmut

---

From: "Salter, Thomas A" <[email-masked]>
Date: Thu, 18 Jan 2001 08:19:40 -0600

> From: Volpers, Helmut [mailto:[email-masked]]
 > Sent: Thursday, January 18, 2001 9:13 AM
 > To: 'Kurt D. Zeilenga'; Jim Sermersheim
	... 
 > Dereferencing should not be the expected behavior.

How did you arrive at the conclusion that X.500 disallows dereferencing?  I
was convinced by X.509 that dereferencing is required (because Bind should
use Compare to access the entry).

---

From: "Volpers, Helmut" <[email-masked]>
Date: Thu, 18 Jan 2001 15:25:30 +0100

Hi all,

In our implementation it is as X.500 1993 describes it.

Never dereference in a "bind"
if you want to dereference in update operations you have to 
set a special extension control.(default: don't dereference)
If you don't want to dereference for retrieval operations
you have to set a service control (default: dereference)

Helmut

> From: Jim Sermersheim [mailto:[email-masked]]
> Sent: Mittwoch, 17. Januar 2001 00:45
> To: [email-masked]
> >>> "Kurt D. Zeilenga" <[email-masked]> 1/16/01 10:02:19 AM >>>
> When we fall back on operational experience, I think it's 
> important that we hear from more than two vendors. I know 
> Novell's behavior is to not dereference anything except when 
> told to do so in the search operation. I assume the same is 
> true for OpenLDAP. I don't know about any other implementations.
> 
> It'd be nice to have a group of representatives (one from 
> each vendor that wishes to participate) that can give a 
> canonical yes/no/otherwise when polling the implemented 
> behavior of these types of things. Those representatives 
> should be able to research and respond to questions within a 
> reasonable time frame (under 1 week I would hope). I'll leave 
> it up to the chairs as to whether or not they want to 
> formalize such a thing.
> 
> Until then, I'm uncomfortable in making an editorial change 
> based on the knowledge that Novell and OpenLDAP have 
> implemented this particular behavior the same. I haven't 
> heard anything from X.500 vendors as to what their 
> interpretation is either.
> 
> Jim
>

---

From: "Volpers, Helmut" <[email-masked]>
Date: Thu, 18 Jan 2001 15:45:34 +0100

> From: Salter, Thomas A [mailto:[email-masked]]
> Sent: Donnerstag, 18. Januar 2001 15:20
> To: Volpers, Helmut
> Cc: [email-masked]

1. argument:

In X.511

If simple is used, it consists of a name (always the distinguished name of
an object), an optional validity, and an optional password. This provides a
limited degree of security. 

(I interpret this "the distinguished name" that it can only be one for one
object)

2. argument

You have to "common arguments" or extensions for a simple bind where you
have the
possibility to say the server "dereference" or "don't dereference" and I
don't believe
that this functionality have a default to "dereference" and it could not be
changed.

Helmut

---

From: "Salter, Thomas A" <[email-masked]>
Date: Thu, 18 Jan 2001 11:31:05 -0500

> Sent: Thursday, January 18, 2001 9:46 AM
 > To: 'Salter, Thomas A'; Volpers, Helmut

But X.509, Section 6 Simple Authentication Procedure, says 
"2) B sends the purported distinguished name and password of A to the
Directory, where the password is checked against that held as the
UserPassword attribute within the directory entry for A (using the Compare
operation of the Directory);"

The default for Compare is to dereference aliases and the Bind doesn't
contain a service control to override it.

Moreover, an X.500 alias entry is unlikely to contain a UserPassword
attribute, so any attempt to authenticate against an alias is sure to fail.

---

From: "Ramsay, Ron" <[email-masked]>
Date: Fri, 19 Jan 2001 11:25:39 +1100

Thomas,

I find your arguments compelling. I agree that the default in X.500 is to
dereference. As with update operations, it would require an explicit
statement not to dereference for bind if this were the required behaviour.

Ron.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 23 Jan 2001 11:42:50 -0700

I believe some semblance of consensus has been reached on this issue.

- There is some agreement that BindRequest.name is not dereferenced. Compelling arguments include existing behavior among implementations, and the lack of a mechanism to specify alias dereferencing behavior.

- There is strong agreement that ModifyDNRequest.entry is not dereferenced.

- There is semi-strong agreement that CompareRequest.entry is not dereferenced. The arguments are the same as those for bind.

Unless there are enough objections to outweigh current agreements, I'll make the following changes:

4.2 <info added as last sentence of name description>
<-	name: The name of the directory object that the client wishes to bind as. This field may take on a null value (a zero length string) for the purposes of anonymous binds, when authentication has been performed at a lower layer, or when using SASL credentials with a mechanism that includes the LDAPDN in the credentials.
>-	name: The name of the directory object that the client wishes to bind as. This field may take on a null value (a zero length string) for the purposes of anonymous binds, when authentication has been performed at a lower layer, or when using SASL credentials with a mechanism that includes the LDAPDN in the credentials. Note that the server will not perform any alias dereferencing in determining the object to bind as.

4.9 <info added as last sentence of entry description>
<-	entry: the Distinguished Name of the entry to be changed. This entry may or may not have subordinate entries.
>-	entry: the Distinguished Name of the entry to be changed. This entry may or may not have subordinate entries. Note that the server will not dereference any aliases in locating the entry to be changed.

4.10 <info added as last sentence of entry description>
<-	entry: the name of the entry to be compared with.
>-	entry: the name of the entry to be compared with. Note that the server will not dereference any aliases in locating the entry to be compared with.

Jim

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 24 Jan 2001 15:30:29 +1100

Jim,

I thought the consensus on the bind was that servers SHOULD NOT dereference
aliases. You have changed this to MUST NOT.

There was agreement that there was no way to indicate whether compare should
dereference aliases. I think this should be a SHOULD NOT in that you are
trying to make implementations nonconformant retroactively. That is, you are
changing the spec, not clarifying it.

ModDN is different because dereferencing was not the default for updates in
X.500. In that LDAP deferred to X.500 where there was no policy, I believe
that MUST is inappropriate for either bind or compare.

Ron.

-----Original Message-----
From: Jim Sermersheim [mailto:[email-masked]]
Sent: Wednesday, 24 January 2001 5:43
To: [email-masked]
Subject: RE: When to not deref aliases

- There is some agreement that BindRequest.name is not dereferenced.
Compelling arguments include existing behavior among implementations, and
the lack of a mechanism to specify alias dereferencing behavior.

- There is semi-strong agreement that CompareRequest.entry is not
dereferenced. The arguments are the same as those for bind.

Unless there are enough objections to outweigh current agreements, I'll make
the following changes:

4.2 <info added as last sentence of name description>
<-	name: The name of the directory object that the client wishes to
bind as. This field may take on a null value (a zero length string) for the
purposes of anonymous binds, when authentication has been performed at a
lower layer, or when using SASL credentials with a mechanism that includes
the LDAPDN in the credentials.
>-	name: The name of the directory object that the client wishes to
bind as. This field may take on a null value (a zero length string) for the
purposes of anonymous binds, when authentication has been performed at a
lower layer, or when using SASL credentials with a mechanism that includes
the LDAPDN in the credentials. Note that the server will not perform any
alias dereferencing in determining the object to bind as.

4.9 <info added as last sentence of entry description>
<-	entry: the Distinguished Name of the entry to be changed. This entry
may or may not have subordinate entries.
>-	entry: the Distinguished Name of the entry to be changed. This entry
may or may not have subordinate entries. Note that the server will not
dereference any aliases in locating the entry to be changed.

>-	entry: the name of the entry to be compared with. Note that the
server will not dereference any aliases in locating the entry to be compared
with.

Jim

---

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 24 Jan 2001 18:19:56 +1100

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:[email-masked]]
Sent: Wednesday, 24 January 2001 17:29
To: [email-masked]
Cc: [email-masked]; Ramsay, Ron; [email-masked]
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".

---

From: [email-masked] (Richard V Huber)
Date: Wed, 24 Jan 2001 13:49:37 -0500

If the operation will always return invalidCredentials, aren't we
really saying that an alias MUST (or SHOULD) NOT be used as the target
of a BIND?

If that is the behavior we want, fine.  As I said before, access
control issues may well make this the right answer.

But if there is anyone out there who feels they have a real need to
BIND using an alias as the dn, now would be a good time to speak up.

Rick Huber

: To: [email-masked]
: From: "Kurt D. Zeilenga" <[email-masked]>
: Subject: RE: When to not deref aliases
: Cc: [email-masked] (Richard V Huber), [email-masked], [email-masked]
: 
: A few corrections to my last post...
: 
: At 10:29 PM 1/23/01 -0800, Kurt D. Zeilenga wrote:
: >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
: 
: s/as there/as/
: 
: >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.
: 
: s/are to should/should/
: 
: 
: >>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".

---

From: "Ramsay, Ron" <[email-masked]>
Date: Thu, 25 Jan 2001 12:06:09 +1100

The operation will only return invalid credentials if an alias is provided
AND the implementation doesn't dereference aliases on binds AND the bind is
simple.

If aliases are dereferenced, or the bind is SASL, there would seem to be
little reason for returning invalidCredentials.

Does one really need a reason?

What if you are using SASL external but the name in the certificate doesn't
map into your user space?

What if you didn't want to declare your DIT?

Frankly I don't understand why people are getting their knickers in a knot
over aliases.

Ron.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, 25 January 2001 5:50
To: [email-masked]; [email-masked]
Subject: RE: When to not deref aliases

Rick Huber

: Cc: [email-masked] (Richard V Huber), [email-masked],
[email-masked]

---

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 25 Jan 2001 16:34:24 -0700

I think there is sufficient agreement that SHOULD NOT is the best (or least-evil) in regard to bind. I also feel that people agree that modDN can be worded like the other update operations (...server will not...). I don't know where people stand regarding compare. 

The X.500 compare operation deref's aliases (unless told not to). This sways one to believe the server should deref (ala section 3.3 of RFC 2251). Implementors likely don't deref on a compare. There is no way in LDAP to prevent deref on a compare, so following that type of pattern, one may be led to believe the server shouldn't deref.

Requesting feedback so I can get the bunch out of my panties (or knot out of my knickers) and move on.

Jim

>>> "Kurt D. Zeilenga" <[email-masked]> 1/24/01 6:42:04 PM >>>
At 12:10 PM 1/25/01 +1100, Ramsay, Ron wrote:
>In the meantime, I don't think we should hold our breath and SHOULD NOT
>seems a workable solution.

I concur.

---

From: "Volpers, Helmut" <[email-masked]>
Date: Fri, 26 Jan 2001 09:59:16 +0100

I think "should not " is the best solution.

> From: Ramsay, Ron [mailto:[email-masked]]
> Sent: Donnerstag, 25. Januar 2001 02:06
> To: [email-masked]; [email-masked]; [email-masked]

Why should the name in the certificate map into my namespace.
If I have a directory tree which begins with DC=Siemens/...
and Kurt logs in my server with the name DC=OpenLdap/...
He can authenticate agauinst my Server (If I trust his CA)
and I can give him AccessRights or why shouldn't this work ?

Helmut

---

From: "Volpers, Helmut" <[email-masked]>
Date: Fri, 26 Jan 2001 10:09:57 +0100

> Sent: Donnerstag, 25. Januar 2001 02:11
> To: Kurt D. Zeilenga; Jim Sermersheim
> Regarding your last statement, I don't regard it as a 
> specification error in
> X.509. (It is actually an authentication issue, not a protocol issue.)

Why a specification error ?

This section in X.509 describes on an abstract level how one user A
authenticates himself to another user B and how they may use the Directory
Service in doing so. It does not describe the procedure that has to be run
within the DSA when a User wants to authenticate.

But even this procedure describes that "the distinguished name" of a user
is treated. What this means is described in X.501 9.1 and 9.2.
"Distinguished name", "alias name" and "directory name" are clearly
defined to mean different things. There may be several "distinguished
names" of an object, but they differ only in contexts of attribute values
involved, not really in the attribute values themselves. The NOTE in 9.2
makes it quite clear: "The set of names of an object thus comprises the
set of alias names for the object, together with the distinguished names
of the object.

X.509 6 2) speaks of "the purported distinguished name" of a user. This
cannot be an alias name. The description for other operations in X.511
explicitly speak of "Names", that might be dereferenced if they involve
aliases. Of course a compare operation may be used by user B to
authenticate user A, but as he has nothing but the distinguished name of
A, this compare operation cannot dereference aliases at this place.

Helmut
> 
> However, if you could get the X.500 specs amended, I agree 
> that the LDAP
> statement could be strengthened. Are you able to present it 
> to the X.500 WG?
> 
> Sent: Thursday, 25 January 2001 6:08
> To: Jim Sermersheim
> Cc: Ramsay, Ron; [email-masked]
> At 11:36 AM 1/24/01 -0700, Jim Sermersheim wrote:
> >Regarding bind, you're right. Concensus seems to be SHOULD 
> NOT (premature
> post on my part). Though I don't believe there has been as 
> much discussion
> regarding compare, most of the arguments are the same. I'll 
> tentatively
> amend.
> >
> >Regarding the use of the SHOULD NOT imperative; it would be 
> useful to add
> text explaining "why not". Kurt, you  mentioned security 
> issues, what are
> they--and do they apply to the compare operation? I don't 
> like adding SHOULD
> NOT just because we think something is wrong but we don't 
> want to break
> existing implementations. 
> 
> Without the statement the specification can be interpreted multiple
> ways, this leads to interoperability problems.  The SHOULD NOT
> clarifies what the intended behavior is while not disallowing
> implementations which have implemented some other behavior.
> 
> I do not believe it necessary to state in the actual specification
> why a particular imperative exists is general.  Of course, key
> interoperability issues and security considerations should be
> discussed within the specification.
> 
> The primary security issues related to aliases and authentication,
> authorization, and access control is related to use of alternative
> names and under specification of semantics (especially in error
> cases).
> 
> I actually believe X.511 nor LDAP did not intend aliases to be
> dereferenced during bind operations.  I view this as a specification
> error which should be corrected in both X.511 and LDAP.
> 
> Kurt
> 
> 
> >Or am I alone in thinking phrases like: "In order to work 
> with existing
> implementations, the server SHOULD NOT do xyz." makes for 
> sloppy protocol?
> >
> >Jim
> >
> >
> >>>> "Ramsay, Ron" <[email-masked]> 1/23/01 9:30:29 PM >>>
> >Jim,
> >
> >trying to make implementations nonconformant retroactively. 
> That is, you
> are
> >Unless there are enough objections to outweigh current 
> agreements, I'll
> make
> >the following changes:
> >
> ><-      entry: the Distinguished Name of the entry to be 
> changed. This
> entry
> >>-      entry: the Distinguished Name of the entry to be 
> changed. This
> entry

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 29 Jan 2001 12:45:43 +1100

Helmut,

If your question was directed to me, my answer would be: Why have any users
in the directory. If you can validate their login without reference to a
user entry then you don't need to store users in the directory.

Conversely, if you use user entries to validate binds, then you presumably
will require entries for 'external' users.

Ron.

-----Original Message-----
From: Volpers, Helmut [mailto:[email-masked]]
Sent: Friday, 26 January 2001 19:59
To: Ramsay, Ron; [email-masked]; [email-masked];
[email-masked]
Subject: RE: When to not deref aliases

Helmut

---

From: "Ramsay, Ron" <[email-masked]>
Date: Mon, 29 Jan 2001 16:29:32 +1100

Steven,

Thank you for the clarification.

I see how X.511 distinguishes between distinguished name and directory name
and that the bind argument uses a distinguished name.

Ron.

-----Original Message-----
From: Steven Legg [mailto:[email-masked]]
Sent: Monday, 29 January 2001 14:55
To: Ramsay, Ron; 'Volpers, Helmut'; 'Kurt D. Zeilenga'; 'Jim
Sermersheim'

Ron,

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ramsay, Ron
> Sent: Monday, 29 January 2001 13:05
> To: Volpers, Helmut; Kurt D. Zeilenga; Jim Sermersheim
> Huh?
> The note in Section 9.2 of X.501 actually says:
>
> Note - The set of names of an object thus comprises the set
> of alias names
> for the object, together with the distinguished name of the object.
>
> The difference between this and what you wrote is that
> 'distinguished name'
> is singular. (I don't understand why you went on about
> attribute values - I
> think it is missing the point.)

Helmut was quoting from the 1997 or 2000 edition of X.501, which uses
the plural, "distinguished names", because of the introduction of
contexts on attribute values. An entry is permitted to have more than
one RDN, where the different RDNs are differentiated by the contexts
on the distinguished values. Consequently, an entry can have multiple
distinguished names in the absence of any alias entries.

>
> The definitions in 9.1 do not describe different 'things' but
> are different
> descriptions of the same thing. For example, distinguished
> name is defined
> syntactically in terms os RDNs. Semantically, a directory
> name is a name
> that denotes an object. The fact that there may be many
> directory names for
> an object is due to the presence of aliases, not the
> mumbo-jumbo about the
> true significance of an attribute value. An alias name is 'an
> alternative
> name for an object'. (It is curious the the punctuation seems
> to be American
> but the dictionary seems to be English!) The 'purported name' is any
> distinguished name which purports to be (or pretends to be,
> or appears to
> be) a valid name for the operation (here, bind).

I agree with Helmut. The editor(s) of X.501:2000 appear to have been
consistent in their use of terminology for names. I think it is clear
that an alias name for an entry is not a distinguished name,
though it is a name, a directory name and an RDNSequence.
The third note in clause 9.7 of X.501:2000 is particularly telling:

"NOTE 3 - Because only the object entry and its superiors are involved,
distinguished names of objects can never involve alias names."

The immediately following sentence is: "Alias entries also have
distinguished
names; however, this name cannot be the distinguished name of an object."

>
> Anyway, so much for the semantics. Thomas and I are waiting
> for you to point
> to the line in any X.500 standard that says aliases may not be used in
> binds. I think you can't do it.

The name in a SimpleCredentials in a BindArgument (X.511:2000) is explicitly
a distinguished name, not a name or a directory name, so alias names
are excluded by clause 9 of X.501:2000.

The name in Read, List, Compare or Search is not explicitly a distinguished
name, it's an RDNSequence, and the descriptions cover the possibility that
the name is an alias name.

That seems like a clear and deliberate distinction to me.

Regards,
Steven

> Sent: Friday, 26 January 2001 20:10
> To: Ramsay, Ron; Kurt D. Zeilenga; Jim Sermersheim
> > >There was agreement that there was no way to indicate
> whether compare
> > should

---

From: "Salter, Thomas A" <[email-masked]>
Date: Tue, 30 Jan 2001 11:04:29 -0500

I finally found a definitive statement in X.511, 8.1.2 Directory Bind
arguments:  "If simple is used, it consists of a name (always the
distinguished name of an object), ... "

Since aliases are entries but not objects they are explicitly excluded from
use in the Bind.

I guess we are now all in agreement that an alias cannot be used as the DN
of a simple bind.

 > Sent: Sunday, January 28, 2001 10:55 PM
 > To: 'Ramsay, Ron'; 'Volpers, Helmut'; 'Kurt D. Zeilenga'; 'Jim
 > Sermersheim'
 > > > >server will not dereference any aliases in locating the 
 > entry to be
 > > > compared
 > > > >with.
 > > > >
 > > > >Jim
 > > >
 > >
 >

---

From: "Jim Sermersheim" <[email-masked]>
Date: Wed, 31 Jan 2001 18:22:04 -0700

Sorry, I miscommunicated what I intended to say. I meant to say there are those who think it should say (choice a): "The server SHOULD NOT perform any alias dereferencing in determining the object specified in the name" and others that would rather it say (choice b): "The server will not perform any alias dereferencing in determining the object specified in the name".

Replace my use of "MUST NOT" below with choice b.

>>> "Kurt D. Zeilenga" <[email-masked]> 1/31/01 5:56:33 PM >>>
Under the guidance provided by RFC 2119, Section 6 for use
of Imperatives, I do not believe there is sufficient reason to
use a "MUST NOT" here.

Kurt

At 05:26 PM 1/31/01 -0700, Jim Sermersheim wrote:
>>>> "Salter, Thomas A" <[email-masked]> 1/30/01 9:04:29 AM >>>
>This was pointed out in http://www.OpenLDAP.org/lists/ietf-ldapbis/200101/msg00018.html, http://www.OpenLDAP.org/lists/ietf-ldapbis/200101/msg00035.html, http://www.OpenLDAP.org/lists/ietf-ldapbis/200101/msg00109.html and another subthread.
>
>Through all of this, we _haven't_ been in agreement.
>
>After looking at this long-winded thread, I noticed that four people have settled on the SHOULD NOT proposal (kz, lp, hv, rr). While another four (th, rh, ts, js) now think it should be a MUST NOT. Let me know if your opinion is being mis-read.
>
>I believe that most people in the SHOULD NOT camp agree that the specification (X.511, 8.1.2) clearly disallows the name of an alias to be passed in a simple bind, but are settling on SHOULD NOT for interoperability reasons. I note that implementations that currently dereference during a bind have always been at odds with the specification (given one agrees with RFC 2251, 3.3 and Thomas's assesment of X.511, 8.1.2). And thus, I'm not sure why special considerations are being made. So far, I've only heard of two servers that do this (and it's optional on one of those).
>
>I also believe most people in the MUST NOT camp will reluctantly say they don't mind it being a SHOULD NOT.