Subject: Re: LDAP URI scheme that specify alternative transport protocols

From: [email-masked] (Mark C Smith)
Date: Wed, 01 Dec 1999 11:04:24 -0500

"Kurt D. Zeilenga" wrote:
> 
> One of the problems facing LDAP (and other application protocols)
> is how to specify URIs that indicate use of an alternative transport
> protocol.  This problem stems from the need to represent LDAP knowledge
> references which indicate the transport to use when the referred to
> server supports/requires alternative transport protocols.
> 
> For example, LDAP can be utilized over TCP or over TLS (versus
> StartTLS).  In fact, LDAP can be utilized over any transport
> which provides a reliable byte stream.
> 
> We (and I believe other vendors) are currently extending our LDAP
> implementation to support a number of other transport protocols
> such as Local IPC and TLS.  The current approach is to define a
> URI scheme per transport protocol, ie:
>         ldap://host:port/
>         ldaps://tlshost:port/
>         ldapi:///
> 
> [Note: StartTLS could be handled using the ldap: scheme
> with an extension <ldap://host/dc=openldap,dc=com????tls>.
> Maybe we should document a URL format for StartTLS in the
> TLS draft?]

We (Sun-Netscape Alliance) already support the ldap: and ldaps:
schemes.  Of course ldaps: is not a standard.  In the past, the argument
was made that a client can decide whether to use TLS after they connect
using regular LDAPv3, so there is no need for an ldaps: scheme or a TLS
option.  But I believe it is sometimes important for clients to be given
a strong hint that they should use TLS.

By the way, what is the ldapi: scheme?  Is that the "LDAP over a
machine-local transport" idea (like using a UNIX domain socket)?

> This problem is not unique to LDAP.  Numerous application protocols
> support multiple transports.  Though this can be handled by adding
> additional URI scheme for each transport protocol supported by each
> application protocol, an extensible mechanism is desirable.

I agree -- this is a general problem.  And therefore I think it should
be handled in a URI-focused group.  This same issue must've been
discussed by those who worked on RFC 2396.  Certainly if you extend the
generic URI syntax, 2396 will need to be updated.

> I have two approaches that might be workable that I would like to
> discuss:
>         ldap://host:port/
>         ldap+transport:://host:port/
> 
> or
>         ldap://host:port/
>         ldap[transport]:://host:port/
> 
> where transport is tcp, tls, ipc or other transport protocol
> identifier.
> 
> As this could be extended to support other application protocols,
> it may be appropriate to move this discussion into another forum.

I wonder if the scope of our problem is really just differentiating
between TCP and TLS+TCP transports?  If so, then maybe having one extra
URL scheme per protocol is tolerable.  That simple solution has been
shown to work.

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 1 Dec 1999 09:21:43 -0800 (PST)

TLS is not a transport protocol; it requires a stream-oriented transport
protocol underneath it to handle things like packet reordering, endpoint
addressing, etc.  TLS is a security-oriented session layer.  When we
considered this problem 2-1/2 years ago (see the ASID list archives from
early-mid 1997) we came to the conclusion that it is best to allow the use
of a session layer (ie, TLS) to be negotiated in-band rather than via port
probing.  This led to the ldapv3-tls spec (which was essentially finished
2 years ago), and the intentional removal of an ldaps: scheme from what
became RFC 2255.  The same approach has been taken with other application
protocols.  At this point there is no justification for an ldaps: URI
(other than historical), and many reasons why it's a bad thing to put into
practice, especially in knowledge references.  Even the HTTP group has
specified a way to negotiate TLS in-band due to the observed problems
that the https: scheme creates.

It might be useful to put something into a URI indicating that TLS should
be used by the URI interpreter.  This falls not into the category of
transport but into the category of specifying security policy (sorry, the
P-word again).  Any scheme to permit specifying security policy in a URI
would be woefully deficient if the only expression it allowed was "use
TLS".  The writer of a URI would also want to be able to specify what TLS
ciphersuites to use, whether to authenticate and how, what SASL mechanisms
are acceptable, etc.  There was some work along this line (I think in the
IMAP context) that I think fizzled due to the obvious complexity of this,
and the realization that jamming security policy into a URI is probably a
bad idea in most cases.  But it may be that the time is ripe to try this
again.

Regarding actual transport specs, like IPC or some store-and-forward
transport as Alexis suggests, note that according to RFC 2396 the part of
the URI that indicates the use of a particular IP-based transport is the
"hostport" construction:

      hostport      = host [ ":" port ]
      host          = hostname | IPv4address
      hostname      = *( domainlabel "." ) toplabel [ "." ]

I would think that the right way to indicate an alternative transport
would be to have some other format in this field that indicated the
transport and the params it needs.

 - RL "Bob"

---

From: Mark Wahl <[email-masked]>
Date: Wed, 01 Dec 1999 11:39:18 -0600

> There was some work along this line (I think in the IMAP context) that I 
> think fizzled due to the obvious complexity of this, and the realization 
> that jamming security policy into a URI is probably a bad idea in most 
> cases.  But it may be that the time is ripe to try this again.

There seems to be three issues:
 - what aspects to model
 - how to represent them
 - how to put them into URIs

The RESCAP BOF dealt with the middle and a bit of the first.  

Those who are interested in this topic might want to talk to the RESCAP 
chairs about this to find out if there is a mailing list.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 01 Dec 1999 18:44:16 +0100

It seems to me that the pc thing to do is to have a root-DSE entry which 
describes the various modes of transport supported by the server. I 
assume that ldap must always be supported over tcp. It is then up to the 
client to (as usual) learn the capabilities of the server using ldap/tcp
and then use whatever transport/SASL mech/extensions/whatever the client
understands and/or cares about. Why try to stick all of that in to URIs?

	Cheers

---------------------------------------------------------------------
Leif Johansson				Phone: +46 8 164541		
IT- and media services
Stockholm University 			email: [email-masked] 	

<This space is left blank for quotational and disclamatory purposes.>

---

From: [email-masked] (David Boreham)
Date: Wed, 01 Dec 1999 14:32:53 -0800

Something extra to throw into the ointment here:

Sometimes (often) it isn't convenient to wire the
transport selector into the knowledge reference.
It's sometimes useful to have the client decide
based on its own policy. Other times it's useful
to generate the transport selector from policy
within the DS.

We've had to do some evil hacks in the products
in this area, and I'd be glad to see the problem attacked
along with the syntax for transport slection.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 01 Dec 1999 15:19:05 -0800

>generic URI syntax, 2396 will need to be updated.

I agree that extensions to RFC2296 should be discussed
in a URI-focused group.  Does any one suggests on a more
appropriate forum for such?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 01 Dec 1999 15:39:40 -0800

At 11:04 AM 12/1/99 -0500, Mark C Smith wrote:
>option.

Note also that URI are often provided by users (such as to an
Web browser with ldap: support).  The user needs a mechanism
to describe how to do the search in situations where the client
may not be albe to discover how to do the search through feature
discovery.

>But I believe it is sometimes important for clients to be given

An URI extension would be a pretty strong hint.

I believe we should add extension to allow specification within
URIs the SASL mechanism and Transport Security Layer requirements.

TLS Required, SASL "External" recommended:
  ldap::///????sasl=external,!tls

DIGEST-MD5 Recommended
  ldap::///!sasl=digest-md5

----
Kurt D. Zeilenga		<[email-masked]>
Net Boolean Incorporated	<http://www.boolean.net/>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 02 Dec 1999 10:21:38 +0100

> may not be albe to discover how to do the search through feature

When exactly is the client not able to discover the capabilities
of the server? The answer is: when the server does not support 
at least read only access to the parts of the DIT (usually the 
root DSE) where capabilities and/or policy is kept. IMHO the natural 
thing to do is to mandate that ldap servers must always implement 
ldap/tcp and allow read-only access to the root-DSE through that 
transport. I am not sure this is is rfc2251 but maybe it should 
go into the rev?

Then all you have to do is to figure out the schema for this stuff.

	Cheers Leif

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 02 Dec 1999 03:30:23 -0800

At 10:21 AM 12/2/99 +0100, Leif Johansson wrote:
>of the server?

We only provide a mechanism for advertising features, we provide
no mechanism that states when a particular feature is may or may
not be used.  In many cases, the only way to discover which
features may be used in a specific context requires client to
have some apriori knowledge or to do a bit of trail and error.
However, the number of possible features combinations makes trail
and error infeasible.  Though one could attempt to define
mechanism to represent all the allowed feature combinations
in some general context (such as which controls can be combined),
discovery of which features are applicable within the context
of a operation or set of operations is a whole other ball game.

Specifically to authentication, the server may support dozens
of sasl mechanisms, however only a few mechanims may be
appropriate for this particular user.  For example, the server
may advertise that it supports DIGEST-MD5, S/Key, and
Kerberos mechanisms.  The client as no method it can use to
determine which is appropriate for the particular user
without attempting each.  Clearly the user may desire to
offer suggestions on which mechanism to try (or require).

I believe the ldap: URI scheme should be extended to be able
to fully describe the set of operations associated with the
LDAP search.  This should include describing allowed/required
bind operations, allowed/required StartTLS, allowed/required
search controls.

>The answer is: when the server does not support 
>root DSE) where capabilities and/or policy is kept.

We only provide a mechanism that allows servers to advertise
the existance of features.  We do not provide mechanism to
describe how, when, and by whom they may be used.

Kurt

----

---

From: Leif Johansson <[email-masked]>
Date: Thu, 02 Dec 1999 13:48:18 +0100

> describe how, when, and by whom they may be used.

Now you are talking policy again :-). This, I believe has been
made clear by several threads on this list, is a difficult 
problem -- recall the recent C-api policy discussion for instance.
Do you claim that you can find a way to map all of that to URIs and
more important: should you do it even if you could?

	Cheers Leif

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 02 Dec 1999 07:44:34 -0800

>more important: should you do it even if you could?

No and no.

I (a user) wants a way of express my apriori knowledge to the
client (say an off the shelf general purpose (LDAP-aware) web
browser) so that it can perform a LDAP search on my behalf.
The LDAP search operation requires binding to the directory
using a standard-track SASL mechanism and allows us of a
standard track extended operations prior to performing the
search.

ldap:://server/dc=openldap,dc=org????!tls,!sasl=external

I believe it much easier to provide a mechanism(s) for users
to impart their apriori knowledge to clients then it is define
a standard, general mechanism that servers may use to describe
to clients when, how, what, and whom may perform a simple, single,
secure search (let alone describing policy affecting other
sets of operations).

I also believe we need experience on methods for expressing
the user apriori knowledge to the client before we can hope
to be able to design and deploy mechanism which eliminate
the need for user's to have apriori knowledge. 

----