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

From: Andrew Probert <[email-masked]>
Date: Wed, 1 Sep 1999 15:05:34 +1000

In an NT world, you can actually configure multiple IP addresses for a
single card and 
thereby use well known ports for each process e.g.

ldaps://server1a.myorg.com
ldaps://server1b.myorg.com

Where they are both on the same box!

By the way is there a well-known port for LDAPS ?

Andrew Probert
Rotek Consulting   http://www.rotek.com.au
a Division of Secure Network Solutions http://SecureNet.com.au
Tel  +61 3 9690 8877
Mobile +61 409 413 028
Fax +61 3 9690 8171

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, September 01, 1999 3:00 PM
To: Ed Reed; [email-masked]
Subject: Re: RFC2255 - LDAP URL Format question...

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: "Ed Reed" <[email-masked]>
Date: Wed, 01 Sep 1999 08:56:44 -0600

Thanks, Bob - I agree that matters, like the use of StartTLS, that don't
need to be exposed in the URL should not be.  As you say, the
requirement or option choice can and should be made as part of the
handshake and/or policy advertised by the DSA.

I think the ldaps:// scheme needs to be documented for general use, though,
and I'm glad to see in Mark's note that we can do that without having to reissue
2255.  Whether that should be published as informational or standards track
is, at that point, less important...it is, after all, contemporary albeit temporary
practice, soon to be relegated to legacy status (we hope!)

I'd encourage Netscape to write it up, since they're using it now, at their
convenience.

Ed

=================
Ed Reed, Technologist
Novell Product Management
+1 801 222 3944 (new number!)

>>> "RL 'Bob' Morgan" <[email-masked]> 09/01/1999 01:11:48 >>>

> ..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: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 1 Sep 1999 17:18:05 +0000 ( )

On Wed, 1 Sep 1999, Ed Reed wrote:

> I think the ldaps:// scheme needs to be documented for general use,
> though, and I'm glad to see in Mark's note that we can do that without
> having to reissue 2255.  Whether that should be published as
> informational or standards track is, at that point, less
> important...it is, after all, contemporary albeit temporary practice,
> soon to be relegated to legacy status (we hope!)

Mark's note said that URL extensions can be documented without changing
2255, but ldaps: is not an extension to the ldap: scheme defined in 2255,
it is a different scheme.  I note that the description of https:
(draft-ietf-tls-https-02.txt) is being put forward as Informational; I
would think that any documentation of ldaps: would also be Informational.
I refer people to the last three weeks of the ietf list for info on how to
do an Informational document (8^); but I agree this is worth writing down
if only to point out that it's not standard.

As to whether it is reasonable and necessary to define methods for
specifying use of security features as URL extensions, I remain skeptical.
I think effort is better spent on standard approaches to defining client
and server security policy.

 - RL "Bob"