Subject: [ldapext] RE: Complex knowledge information

From: "Howard Chu" <[email-masked]>
Date: Fri, 23 Apr 2004 01:50:08 -0700

> From: "Jim Sermersheim" <[email-masked]>

> All,
>
> RFC 3296 defines a 'ref' attribute for holding knowledge information.
> The format of this is a labeledURI. Each URI holds knowledge
> information
> about another service that can be used to progress an operation
> affecting this part of the tree.
>
> We are seeing needs for extra data to be associated with each remote
> address (each value of the ref attribute). Examples of this include:
>
> - Authentication information (instructions on how to authenticate to
> the remote service)
> - Authorization information (assertions regarding the authorization to
> be used on the remote service)
> - Cost-related information
> - Schema mapping information (name mappings, syntax mappings)
> - Data transformation rules (especially for URI's pointing to non-LDAP
> DSAs)
> - Name resolution information (i.e. entryUUID of remote object)
>
> There is other information that applies to the group of URIs in a
> referral, but that's a different thread.
>
> The question is twofold:
> 1) What is the preferred way to represent this type of auxiliary
> knowledge information in the directory?
> 2) What is the preferred way to represent this type of auxiliary
> knowledge information in operations returning a referral (or
> searchResultReference)?

I think the answers depend a great deal on the actual usage scenarios. In
particular, it depends on whether the first server's referral points to
another trusted/local server, or if it points to a foreign/unknown server. I
suppose if you know enough about the remote server to have schema mapping,
data transformation, and name resolution information, then you probably know
a fair amount of other things about it too.

In the case of trusted/cooperating servers, my preference is for the server
to maintain all of this information internally, chain the queries, and return
the mapped results to the client transparently. In this case,
authentication/authorization is also handled by the chaining server.

In the case of a foreign/untrusted server, generally it would be
inappropriate for the local server to automatically tell the client anything
about how to authenticate/authorize.

Probably not a very useful reply, but that's how I see things at the moment.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: Michael Ströder <[email-masked]>
Date: Fri, 23 Apr 2004 16:58:32 +0200

> about how to authenticate/authorize.

Since most times I have the client-side view I'd like to focus on 
authentication information in LDAP URLs.

Are there any client implementations out there using the bindname extension 
of LDAP URLs? If yes, how do they treat it? My web2ldap simply presents a 
login form asking for the credential (password) for this bind DN.

Are there any server implementations setting bindname extension in a 
referral LDAP URL? How should a client treat such a referral URL?

Now if a LDAP server would sent back a referral with bindname extension set 
in the referral URL I would simply act the same way as described above: 
Present a login form to the user before following the referral.

Any security considerations?

Furthermore I'd also like to have a mechanism like that for specifying SASL 
related authentication information in a LDAP URL:
- StartTLS ext. op. SHOULD/MUST be used
- SASL authc ID
- SASL authz ID
- SASL realm
- SASL mechanism

I can easily use LDAP URL extensions for these off course but what do the 
list members here think about this approach?

Ciao, Michael.

---

From: Stig Venaas <[email-masked]>
Date: Tue, 27 Apr 2004 13:20:26 +0200

> login form asking for the credential (password) for this bind DN.

I have an LDAP application where I use LDAP URL for configuring server,
search base etc. but also bindname and x-bindpw. I found several other
applications (including web2ldap if I remember correctly) that supports
x-bindpw. I think it's convenient to have an LDAP URL in the configu-
ration file of my client containing all the LDAP related parameters.
As for security, it doesn't really matter if a plain text password is
part of the URL or configured separately since the URL is never exposed
anywhere else. I would be much more concerned about referrals.

Is anyone else interested in standardizing bindpw, there are lots of
implementations and also an old internet draft mentioning it. Do a
google search for "x-bindpw" and you will find a lot. Would some
other name be appropriate? Something that can be used with different
types of credentials for different authentication schemes?

Stig

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 27 Apr 2004 14:58:15 -0700

At 04:20 AM 4/27/2004, Stig Venaas wrote:
>anywhere else.

I'd argue that there are security considerations here.
I don't think it wise to assume all URL handlers will
understand and recongize and treat appropriately an
LDAP URL which happens to contain an extension
(standardized or not) a password field.

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.

>I would be much more concerned about referrals.
>
>Is anyone else interested in standardizing bindpw,

Well, given that bindpw is about to be un-standardized,
I see little point it trying to standardize bindpw.
I also think there would be significant resistance to
standardizing bindpw without like mechanisms to support
LDAP's mandatory-to-implement strong authentication
mechanism (SASL/DIGEST-MD5) and Start TLS (which needs
to be implemented if one supports simple password
authentication).

Personally, I cringe at the thought of placing
authentication information into the locator.

Kurt

>there are lots of

---

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

> 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: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Apr 2004 12:38:45 +0100

Michael Ströder wrote:

> Furthermore I'd also like to have a mechanism like that for specifying 
> SASL related authentication information in a LDAP URL:
> a) StartTLS ext. op. SHOULD/MUST be used
> b) SASL authc ID
> c) SASL authz ID
> d) SASL realm
> e) SASL mechanism

Sounds like a good idea to me.

If you want to design something that is consistent with other protocols, 
have a look at RFC 2192 (IMAP URL), section 3. It can deal with b) and e).
d). has limited applicability (basically for DIGEST-MD5). Having a) and 
c) would be nice too.

> I can easily use LDAP URL extensions for these off course but what do 
> the list members here think about this approach? 

Adding this as an LDAP URL extension seems like a less intrusive change.

Alexey
__________________________________________
Isode Limited, http://www.isode.com

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html
__________________________________________

---

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