Subject: I-D ACTION:draft-ietf-ldapext-cldap-00.txt

From: [email-masked]
Date: Thu, 01 Jun 2000 06:31:35 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the LDAP Extension Working Group of the IETF.

	Title		: Connection-less Lightweight Directory Access Protocol
	Author(s)	: L. Johasson, R. Hedberg
	Filename	: draft-ietf-ldapext-cldap-00.txt
	Pages		: 10
	Date		: 31-May-00
	
This memo describes modifications to LDAP version 3[1] to allow
transport of a subset of the LDAP protocol over connection-less
transport. The case of UDP/IP is covered in detail in this memo but
other transport layers are possible.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ldapext-cldap-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ldapext-cldap-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ldapext-cldap-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 01 Jun 2000 06:19:36 -0700

RFC2222, 3.:
   The Simple Authentication and Security Layer (SASL) is a method for
   adding authentication support to connection-based protocols. 

I-D, Abstract:
   transport.

I-D, Security considerations

   Unlike CLDAP verison 2[3] it is possible for a CLDAPv3 client to
   establish a secure association to a CLDAPv3 server by a SASL bind
   which can establish an integrity or security layer. 

How?

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 01 Jun 2000 08:26:37 -0700

Additional comments:

The document should be updated to use RFC 2119 terminology
statement.  I will assume it uses MUST, SHOULD per 2119.

Section 2:
> Encoded packets must be small enough to fit inside a datagram
> no bigger than the size of the MTU of the transport mechanism."

Why the MUST?  Would the protocol not work if the MTU was
exceeded?  I would think SHOULD would sufficient... with a
statement as to why (ip fragmentation?).

Section 4:
> Therefore the application using CLDAPv3 have to handle packet loss.

And duplication.  And reorderring.

> One way of aiding this would be to add something like a
> packet sequence number in the PDUs sent from the server
> to the client, how this is to be done is outside the scope
> of this document.

I would argue that this complete within the scope of this
document and should be addressed in the I-D.

In addition the draft should address issues regarding the
association (or lack thereof) of a session to a particular
client.

> They (servers) must also check the version field of the LDAP PDU

An LDAP PDU does not have a version request.

> 6. Security considerations

Given SASL/TLS are designed for connection-oriented application
protocols, I suggest looking into use of IPSEC transport mode
to provide security services.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 05 Jun 2000 17:41:25 +0200

Hi Kurt,

Thanks for keeping us on the straight and narrow :-) Your comments
were right on the mark as usual.

> statement.  I will assume it uses MUST, SHOULD per 2119.

absolutely

> statement as to why (ip fragmentation?).

Handling fragmentation would (imho) make the protocol too complicated
to bother with as an alternative to tcp. Reordering and retransmission
is "trouble" enough (see below). The note imho MUST be a MUST but the
reason SHOULD (MUST ?) be clearly stated!

> And duplication.  And reorderring.

agree, but (see below) ...

> document and should be addressed in the I-D.

Well, any solution would seem to require adding controls (or other protocol
elements). We were hoping to move all such additions to experimental drafts.

> An LDAP PDU does not have a version request.

You are absolutely right -- I don't know what got into us here. This note 
must go away. I had a thought when writing this but it was unclear which.

> to provide security services.

You are right again. Do you know the reason why sasl is only specified for
connection-oriented protocols? Would this be "fixable" by amending sasl or
is there some "real" reason behind keeping sasl connection-oriented only.
In anyway specifying IPSEC would seem to be the "right" thing to do.

	Cheers leif

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 05 Jun 2000 09:28:45 -0700

At 05:41 PM 6/5/00 +0200, Leif Johansson wrote:
>to bother with as an alternative to tcp.

CLDAP is not complicated by IP fragmentation.  IP implementations
must support IP fragmentations and applications protocols should
care less of fragmentation occurs or not.  There should be no
interoperability issue.

I concur that fragmentation is expensive, but this fact alone
is insufficient justification for the MUST.

The SHOULD would be sufficient, I suggest something on the
lines of:
  Implementations SHOULD avoid sending PDUs which require
  fragmentation at lower levels as reassembly is expensive.
  Implementations MAY use path MTU discovery or other means
  for determining an MTU restriction.  Implementations
  MUST be capable of accepting and generating PDU of size X.

The latter requirement necessary to ensure an implementation
can respond to a critical (simple) request.  Not sure what
value X should take.

>Do you know the reason why sasl is only specified for

SASL requires connection-oriented, reliable transport by design.
It cannot be easily amended to support connection-less, unreliable
transports.

>In anyway specifying IPSEC would seem to be the "right" thing to do.

Yes, and we'd need to define a secure authentication mechanism
for CLDAP.  I would suggest adding an authentication choice
external [4] which would use lower level credentials exchanged
at lower level to establish CLDAP session level authentication
(and authorization).  That is, it would work like SASL "External",
but be SASL-less.

---

From: Mark Wahl <[email-masked]>
Date: Mon, 05 Jun 2000 12:32:52 -0500

I would prefer that the SASL EXTERNAL mechanism be used to pick up the 
IPSEC credentials to the LDAP level, rather than a new protocol field.

Mark Wahl, Directory Architect, Service Provider/Infrastructure
Innosoft, part of Sun Microsystems, Inc.'s iPlanet alliance

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 05 Jun 2000 11:05:19 -0700

>IPSEC credentials to the LDAP level, rather than a new protocol field.

I agree that SASL/EXTERNAL can and should be used to pick lower
level credentials associated with connection.  Those credentials
can be provided by TLS, IPSEC, or other lower layer associated
with the connection.

However, SASL (including SASL/EXTERNAL) cannot be used with
connectionless protocols, you must have a connection to use
SASL.  CLDAP should not overload/redefine any existing
authentication choice nor any specification of those choices.

Given that Connection-less LDAP cannot make use of SASL, it
should (must) define a separate choice (and specification)
which provide for secure authentication.  This choice can be
based upon SASL/EXTERNAL, but it is not SASL/EXTERNAL as it
would be defined in a manner which supports connection-less
transports.

Kurt

---

From: [email-masked] (Mark C Smith)
Date: Mon, 05 Jun 2000 14:13:01 -0400

>         Filename        : draft-ietf-ldapext-cldap-00.txt

Section 3 says:

   ... Note that it is
   possible for a client to issue a modifying request (add, delete,
   moddn, modify) together with a control or an extended request which
   modifies the directory such that the response is too large to fit in
   a datagram which would make it impossible for the client to know if
   the requested operation was successful or not. For this reason
   servers implementing this protocol must respond with an error of
   unwillingToPerform(53) if such a request is received.

Does the above mean that a server must determine the size of a response
before it actually carries it out?  That might be tricky to implement.

Also, I'd prefer to see a more specific error introduced for this case
(or just use resultsTooLarge).  An unwillingToPerform error may be
returned for other reasons, and it would be nice to unambiguously tell
the client "This can't be done over UDP, please try again over TCP."  In
fact, I'd like to see the client's recommended behavior with respect to
error recovery and use of LDAP over TCP (when a CLDAP request fails)
spelled out in the draft.

It would also be valuable to provide a "scope" or "requirements"
section.  For example, I think a useful CLDAP protocol could omit all of
the update operations (keeping compare and search).

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?

---

From: Bruce Greenblatt <[email-masked]>
Date: Mon, 05 Jun 2000 11:31:51 -0700

>authentication choice nor any specification of those choices.

Why couldn't I write a draft titled "Using SASL/EXTERNAL mechanism in 
connectionless protocols"?  As I read RFC 2222, it only says that it 
defines how to use SASL over connection oriented protocols.  It doesn't 
appear to say that there is no way to ever use SASL/EXTERNAL within UDP.

Bruce

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 05 Jun 2000 12:38:28 -0700

At 11:31 AM 6/5/00 -0700, Bruce Greenblatt wrote:
>connectionless protocols"?

SASL/EXTERNAL is a part of SASL.  SASL is designed for use
by application protocols which use connection oriented transports.
Though one can base a new framework for application protocols
which use connectionless transports, any Standard Track specification
for such must be complete.  Defining a connectionless SASL/EXTERNAL
without connectionless SASL makes no sense to me.  Anyways, such
work would likely be out of scope of CLDAP and LDAPext WG.

CLDAP must provide a secure authentication mechanism designed
for use with the intended transport.   In lieu of a general
framework supporting connectionless transports, I suggest a
simple, yet secure authentication choice be added.  However,
there may be other choices, I would suggest we consult the
Security Area folks for a recommendation in this area.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 05 Jun 2000 12:47:42 -0700

>the update operations (keeping compare and search).

Note that standard track protocol with update operations need
a mandatory to implement secure authentication mechanism....
remove update operations, remove the requirement for secure
authentication...

I would agree with Mark that CLDAP would remain useful
without update operations.

Kurt

---

From: "Booker C. Bense" <[email-masked]>
Date: Mon, 5 Jun 2000 12:47:44 -0700 (PDT)

> appear to say that there is no way to ever use SASL/EXTERNAL within UDP.

- There are two essential "features" to SASL. The first is a means of
choosing authentication and the second is strictly defining what you
have to do successfully authenticate using that method. Both are
heavily dependent on the underlying notion of a "session" to provide
their security. While it might be possible to design a secure
"application profile" for a connectionless protocol, I can't see how
you could do without essentially duplicating the TCP stack. There are
just far too many assumptions inherent in SASL to just blindly 
apply the methods and assume you have done an adequate job of 
security.

- I certainly believe it is possible to have an authenticated
UDP based protocol, but I think you'd be much better off designing
it from scratch rather than attempting to jam one and only one
SASL method into it. 

- While I can certainly see the advantages of CLDAP, I think that
there needs to be a clearly defined scope of what you can and can't
do via the protocol. The application need as I see it is for searching
on at most a few fields and returning a brief answer. There is also
a need for authentication of some sort to allow access control. 
Data integrity and privacy would be useful, but will be very
complicated to implement. ( How do you build "session keys" in the
absence of a session?) The only model I know of that solves these
problems is the tgt service of kerberos, it does it by very strictly
limiting the kinds of requests you can make and the resulting answers
you will get. 
 
- Any attempt to duplicate the full range of ldap will essentially
require reimplementing TCP. A pointless exercise at best. 

- Booker c. Bense

---

From: Bruce Greenblatt <[email-masked]>
Date: Mon, 05 Jun 2000 13:25:32 -0700

>by application protocols which use connection oriented transports.

Yes, I know that.  RFC 2222 (which defines SASL) doesn't say that you can't 
use it inside of UDP as Mark Wahl suggested.  It seems as if it would be 
straightforward to define the mechanism that would allow this to work in 
such a way that the SASL "pick(s) up the IPSEC credentials to the LDAP 
level".  SASL (i.e. RFC 2222) doesn't prevent this, it just doesn't define 
how it works.

Bruce

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Jun 2000 00:27:42 +0200

I think the SASL debate actually evolves out of a deeper problem with the 
CLDAP draft itself:

Is it a specification for running an LDAP session over UDP, or is it a 
specification for running LDAP queries in connectionless mode?

In the first case, the spec is incomplete; it needs to essentially rebuild 
all of TCP's machinery in order to get reliably delivered requests and 
responses.
(Perhaps it wants to use SCTP?)
But the server has to remember which clients are connected; thus, it can 
use SASL.

In the second case, the spec is incomplete, because it needs to guard 
against weird stuff like mismatching responses from old queries with new 
responses, and it needs to pick at least one mandatory-to-implement 
security mechanism if it's going to be applicable to anything but Read.
The server can then just reply to a request and forget about it, saving 
gobs of time by not having state information, just like the DNS does.
But it can't use SASL.

                                Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Tue, 06 Jun 2000 08:25:52 +0200

> before it actually carries it out?  That might be tricky to implement.

No, the server can just choose to refuse to serve anything containing a
control in a modifying request or it can implement something that would
"guess" the size of the reply in some way.

> spelled out in the draft.

Good point, I agree. The recommended client behaviour of fallback to TCP
you indicate is indeed the one we were thinking about and that will need
to be stated more explicitly.

> the update operations (keeping compare and search).

Yes, why not.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Jun 2000 11:37:25 +0200

FWIW, I think the approach of "just" embedding raw LDAP requests in UDP 
packets is wrong; it offers too little support for solving the problems 
noted here.

A better approach would be to update RFC 1798, and include 3 parts in the 
UDP packet:

- A "wrapper" function
- A "control information" block, which could be used for security, 
authentication or just sequence numbers
- An LDAP request or response

It's no accident that this is almost exactly what SNMP does!
I'd like to structure the document set like this:

- A basic standard describing the wrapper, an extremely primitive control
   info block (basically just enough to correlate requests with responses
   reliably), a basic retransmission strategy, and a basic profile saying
   "if you use this simple stuff, only use Search, and expect to be spoofed".

- An extension that describes how to do an adequate security layer (whether
   it's IPSec, SASL-with-secure-session-ID, or something else), how to achieve
   at-most-once semantics for update operations, and an extended
   profile saying "it makes sense to do almost any LDAP operation with this".

This should achieve the goal of making the document the current authors 
want out the door short and easy to write, while not painting ourselves 
into a corner we don't want to be in.

                      Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 06 Jun 2000 10:09:28 +0200

At 09:12 06.06.2000 +0200, Leif Johansson wrote:
>Both and none. In order to be able to use read with access-control you need,
>as someone already pointed out, to be able to identify a session, defined by
>a completed bind which does require something beyond what is provided in the
>draft. For anonymous reads the situation is different.

Then I think we need to be able to tell the difference between the two modes.
And even with anonymous reads, there should be a reason why the client 
trusts the answers from the server.
(The DNS, as currently deployed, has the request ID as its sole "security". 
It's just slightly more than nothing, and clearly not Good Enough.)

Also, if you have a "session" that is entirely unprotected against 
insert/remove attacks, you have a security problem.
Imagine someone inserting extra replies into your search result, for instance.

                  Harald

---

From: Leif Johansson <[email-masked]>
Date: Tue, 06 Jun 2000 09:12:24 +0200

You may not care about reordering of packets in a search response -- the 
searchResultDone packet might be uninteresting for an application where
results not returned within a very short time are dropped anyway -- or even, 
heaven forbid, about loss of packets in a search response. Some applications 
may care to get a reply back from modify-operations :-) This is imho best 
handled with a set of controls and/or exops. 

For instance if you really care about getting all your search responses in 
the right order you can either (sketching here so please forgive some 
handwaving) add a control with a sequence number or create an exop response 
which contained a SEQUENCE OF ldap pdu's. Which is better? I don't know.
Does it absolutely have to go into this draft? I hope not :-)

> all of TCP's machinery in order to get reliably delivered requests and 

Not all of it. Reordering may not be an issue, packet loss may not be an 
issue. An extra set of controls could be considered a tool for selecting which 
aspects
of a full connection is interesting to the application. Having said that I 
absolutely agree that if we get close to finding ourselves implementing tcp
in LDAP/UDP to get basic functionality the project must be dropped.

	Cheers Leif