Subject: Re: RFC2255 - LDAP URL Format question...

From: [email-masked] (David Boreham)
Date: Tue, 31 Aug 1999 21:59:49 -0700

Ed Reed wrote:

> ..How does one indicate, in an LDAP URL, whether LDAP over SSL is to be used to contact an LDAP server at the ip address and socket specified in the LDAP url?
>
> Seems like there needs to be another scheme defined...
>
> Yes, if the well known sockets are being used, then calling out the socket number in the URL might let you know whether SSL is to be used, or not.
>
> But if there are multiple DSAs operating on the same TCP/IP stack, they can't all use the well known SSL LDAP socket, and so we need some way to specify, in the URL, to talk to this host on this socket using SSL.  At least until the last SSL LDAP server is retired (;-)
>
> Have you already addressed this somewhere you can point me, or is this a new "opportunity" to revise 2255 before progression to standard?  I'd also note that the reference 2255 makes to RFC 1738 is obsoleted, now, by RFC2396.

This is roughly how the Netscape implementation works:

The client SDK recognizes "ldaps" urls as meaning LDAP over SSL.
A port number, if present, is used otherwise the default SSL port
number is used.

The server, when returning a referral to a client, re-writes the referral
URL on the fly to the "ldaps" form, if the client itself connected via SSL.

The case where non-default SSL ports are employed is not handled
elegantly. (manual configuration of ldaps referrals with port numbers
would be required).

---

From: Mark Wahl <[email-masked]>
Date: Wed, 01 Sep 1999 00:39:53 -0500

> ..How does one indicate, in an LDAP URL, whether LDAP over SSL is to be used
> to contact an LDAP server at the ip address and socket specified in the LDAP
> url?

It would seem to me that whether to use Start TLS, the successor to the now
obsolete second port, is part of the client's decision, along with
 - what algorithm suite(s) to propose with Start TLS,
 - what credential set to use in the bind,
 - which SASL mechanism when binding if not EXTERNAL,
 - whether to pull schema from the server,
etc.

There is a space in the URL definition for critical and non critical options.
I would propose that a URL could 'recommend' or 'require' the use of Start 
TLS, specific algorithm suites or (better) generic security services such as
data confidentiality or mutual authentication, by the use of standards-track
URL options.  URL options can be proposed in a standards track RFC without 
needing to reissue 2255.  The LDAPEXT working group or its successor would
be currently the most appropriate place for discussion of these kinds of 
options.

BTW, a similar requirement that is not specific to LDAP URLs is how to indicate
what IP level security services to use when contacting particular services for
the first time.   It would be worthwhile to contact other working groups that 
may be investigating this work area and see if there is any commonality or
existing approaches that could be leveraged.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 1 Sep 1999 07:11:48 +0000 ( )

> ..How does one indicate, in an LDAP URL, whether LDAP over SSL is to
> be used to contact an LDAP server at the ip address and socket
> specified in the LDAP url?
> 

Mark's response explains this well, though I might rather say that the use
of TLS is something about which the client and server can negotiate, among
many other things they can negotiate.  Ed, if your server wants to enforce
the use of TLS on connections made to it, then it merely has to be
configured to do so; and it can be made to do this without anyone having
to change the ldap:// URLs that may already be printed on the side of city
buses.  Moreover, a client can choose to use TLS protection, or Kerberos
or Digest protection, when making a URL-initiated LDAP connection,
whenever it wants to (assuming server agreement); unlike say with http://,
which tells the client *not* to use TLS.  You might want to look at
draft-ietf-tls-http-upgrade-02.txt, which proposes a way of getting even
http out of the https: tarpit.

 - RL "Bob"

---

From: [email-masked] (David Boreham)
Date: Wed, 01 Sep 1999 07:02:32 -0700

RL 'Bob' Morgan wrote:

Mark's response explains this well, though I might
rather say that the use

of TLS is something about which the client and server can negotiate,
among

many other things they can negotiate.  Ed, if your server wants
to enforce

to change the ldap:// URLs that may already be
printed on the side of city

buses.  Moreover, a client can choose to use TLS protection, or
Kerberos

which tells the client *not* to use TLS.  You might want to look
at

draft-ietf-tls-http-upgrade-02.txt, which proposes a way of getting
even

Indeed. Mingling service addresses with transport options is evil,

as proven by our experiences with ldaps:// in referrals. I suspect

that if start-TLS were widely deployed, then ldaps:// should be

avoided at all costs. AFAIK unfortunately this is not the case.