Subject: Re: [ldapext] Authentication information in LDAP URLs

From: Michael Ströder <[email-masked]>
Date: Wed, 28 Apr 2004 09:31:13 +0200

Kurt D. Zeilenga wrote:
>>
> In note that LDAPBIS had concerns with bindname not be
> recognized (let alone supported) by all implementations
> and axed it from the revised technical specification.

Uuuh? (Cc:-ed [email-masked])

bindname extension should be left in LDAP URL specification since there are 
existing applications deploying it. web2ldap and various of my custom 
software are using it based on the ldapurl.LDAPUrl class in python-ldap.

Off course there are security considerations with credentials in LDAP URLs. 
I generally do not recommend putting credentials in LDAP URLs.

Ciao, Michael.

---

From: Stig Venaas <[email-masked]>
Date: Wed, 28 Apr 2004 11:05:27 +0200

> I generally do not recommend putting credentials in LDAP URLs.

Agree with all of this, I'm using bindname too. That bindname is in the
specification, doesn't require it to be implemented. At least as I
understand it. And those depending on it, should mark it as critical
when using it. So I don't understand why it should be axed just because
many implementations don't use it. There are still many that do.

Even though I see some good uses for credentials
in URLs, I would not generally recommend it. And I must confess that it's
a danger an URL used in one context might be used in another. There's
some danger that credentials are used in a perfectly safe context, but
that the URL leaks...

Stig

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 28 Apr 2004 12:41:04 -0700

>Uuuh? (Cc:-ed [email-masked])

My categorization of the LDAPBIS WG discussions may be poor
simplification.  Maybe a better simple categorization would
to be to say that the WG recognized that there were a number
of thorny technical issues with this feature and the WG choose
not to tackle them.  Additionally, there were (and still are)
implementation report issues with regard to this feature.

As the feature uses an extension mechanism and should be
Elective as well as truly optional, it is recognized
that the specification for this feature, like many other
extensions, can be separately documented and separately
progressed from the LDAP 'core' technical specification.

Given this, and the lateness of this concern, I will not
entertain (at this time) the question of whether the
specification of this feature should or should not be
reincorporated into the 'core' specification.  Instead,
I encourage you, and others who may believe a new
specification of this feature should be progressed, to
engineer, on an individual basis, an Internet Draft
containing such.

Kurt, LDAPBIS co-chair

---

From: Michael Ströder <[email-masked]>
Date: Thu, 29 Apr 2004 07:55:57 +0200

> progressed from the LDAP 'core' technical specification.

But with removing bindname extension from draft-ietf-ldapbis-url LDAPBIS WG 
breaks existing LDAPv3 implementations. This is a strong contradiction to 
the goal of LDAPBIS WG (as you wrote on LDAPBIS mailing list many many times).

> reincorporated into the 'core' specification.

I strongly disagree here! You're violating the goal of LDAPBIS not to break 
existing LDAPv3 implementations.

Note that bindname extensions in RFC2255 was just LDAP URL syntax, no 
semantics were described there. Which is ok IMO.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 29 Apr 2004 06:48:11 -0700

At 10:55 PM 4/28/2004, Michael Ströder wrote:
>But with removing bindname extension from draft-ietf-ldapbis-url LDAPBIS WG breaks existing LDAPv3 implementations.

No it doesn't.  draft-ietf-ldapbis-url allows extensions such
as bindname, it just doesn't specify them.  bindname is still
specified in RFC 2255.  Publication of draft-ietf-ldapbis-url
will mean that the current specification of bindname is
Historic until a separate specification of bindname is
progressed.  Such reorganization doesn't 'break' any existing
implementation, nor even cause any implementation to be
non-conformant.  It just means these implementation support
a separately defined LDAP URL extension.

>This is a strong contradiction to the goal of LDAPBIS WG (as you wrote on LDAPBIS mailing list many many times).

I disagree.  The goal of this WG, as detailed in the charter,
is to engineer an LDAPv3 "core" technical specification
suitable for progression to Draft Standard.   This has and
will involve reorganization of the technical specification,
including pushing some features out of the 'core'
specification.  This has been discussed many times, including
during our chartering process and as we undertook previous
reorganizations which 'removed' specifications of certain
features from the 'core').

>I strongly disagree here! You're violating the goal of LDAPBIS not to break existing LDAPv3 implementations.

See above.

Kurt