Subject: RE: C API: minor comments

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Mon, 15 Nov 1999 14:43:13 -0800

> -----Original Message-----
> From: Mark Wahl [mailto:[email-masked]]
> Sent: Monday, November 15, 1999 1:14 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Andy Herron 
> (Exchange); Anoop
> Anantha (Exchange); [email-masked]; [email-masked]
> Subject: C API: minor comments
> 
> 
> 
> Two last call comments on the C API regarding unsolicited 
> notifications:
> 
> I recommend that in section 5 we add:
> 
> Implementations of the API SHOULD begin numbering messages with 1, to 
> be able to easily distinguish client-generated requests and 
> unsolicited
> notifications.

Quite probably a bad idea. It means that the IDs are predictable, making it
easier for an attacker to spoof requests or replies. It may not matter as
much with LDAP/TCP, but with LDAP/UDP it would.

How about suggesting that requests be even and unsolicited notifications be
odd?

Paul

---

From: Mark Wahl <[email-masked]>
Date: Mon, 15 Nov 1999 16:49:50 -0600

> How about suggesting that requests be even and unsolicited notifications be

Unsolicited is zero.  How about this instead:

 Implementations of the API SHOULD assign message IDs for client generated
 requests in a range between 1 and 2147483647, to be able to easily 
 distinguish them from unsolicited notifications.

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 15:11:11 -0800

>> much with LDAP/TCP, but with LDAP/UDP it would.

Replies and Responses can just as easily be spoofed if the IDs are not
predictable.

> distinguish them from unsolicited notifications.

I would suggestion:

  API implementations MUST assign a non-zero message ID for client
  requests.  This ensures that all responses with message ID zero (0)
  will be unsolicited notifications.   Typical API implementations
  increment a counter for each request.

Note: the last sentence is consistent with RFC2251.  If this is
a security risk, I suggest adding a security consideration to
both RFC2251 and this draft stating the applications concerned
about spoofing should utilize a secure transport.

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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 15 Nov 1999 15:51:38 -0800

At 04:55 PM 11/15/99 -0600, Mark Wahl wrote:
>
>I assume that when this document is sent to the RFC editors, we will remove
>the paragraph:
>
> Until such time as this document is published as an RFC, implementations
> SHOULD use the value 2000 plus the revision number of this draft for
> LDAP_API_VERSION.  For example, the correct value for LDAP_API_VERSION
> for revision 04 of this draft is 2004.
>
>Correct?  (The reason I had originally suggested an RFC number was to stop
>implementors from shipping products claiming conformance to a standards-track
>specification before the RFC was even published!)

I suggested the above to allow developers to experiment with the
proposed mechanisms.  I concur that should be removed during final
editing.

>In section 9.2 for LDAP_OPT_API_INFO: "If the value received is not recognized 
>by the API implementation, the ldap_get_option() function ... returns an error 
>without filling in any of the other fields in the LDAPAPIInfo structure.".  
>So ldap_get_option() returns -1.  The question is, what does a subsequent call
>to LDAP_OPT_ERROR_NUMBER return to signal this?  Since LDAP_OPT_API_INFO 
>allocates memory, it can't be LDAP_NO_MEMORY, and none of the others look
>suitable.  I propose that this section state that a subsequent call to get
>the error number will indicate LDAP_NOT_SUPPORTED.
>
>In section 9.2 the C API omits to mention that the caller must 
>ldap_memfree(ldapai_vendor_name).
>
>In section 9.2 I'm having trouble figuring how to use the feature info to 
>obtain interoperability between a client from A, a feature from X and a 
>library from Y.

It likely could use some clarification.  I've experimented with exactly
this issue in our development branch and attempted to clarify some uses
of feature discovery within my errno/concurrency drafts.

> 1. How do I find out _what_ the feature is?  (A client control? a new call?)

The mechanism only allows you discover whether the feature
exists or not, but does not describe the feature itself.

You likely need to consult your <ldap.h> and your vendors documentation.

Note: the existance of a new client control may not necessilary be
described as a feature.  I think Mark Smith posted some comments in
this area a while back.

> 2. How do I find out whose feature it is?  (An internal version number by
> itself is not useful - suppose vendor X adds a feature to vendor Y's base
> library - there is no guarantee that X and Y's numbering plans are 
> synchronized)

The library providing ldap_get_option should provide a
mechanism for you to discover who provided any feature listed via LDAP_OPT_API_FEATURE_INFO.

> 3. How do new features register themselves so that ldap_get_option() will know
> about them?

Not specified, hence implementation specific.

> 4. If the number could be an RFC or could be an internal number which might
> look like an RFC number, how does a client do a sensible comparison on it?

The only sensible comparison is equality.

>I propose we consider removing the feature info request of ldap_get_option()
>from this document and consider moving it to its own document.  I suspect we 
>will have enough trouble at present just getting source code interoperability
>between different client libraries, that binary compatibility is still too far
>away.

Some vendors offer multiple libraries which share a common <ldap.h>
and rely on ldap_get_option LDAP_OPT_API_FEATURE_INFO to allow which
features are provided dynamically.  See my errno and concurrency
drafts on one approach (zeilenga-ldap-errno, section 5. "Advertising
Features").

I would not be opposed to moving feature discovery into separate
document.

>If you disagree, then I suggest then that we REQUIRE the version number
>to be an RFC number.

I would be opposed to limiting the version number to a RFC number.
I believe non-RFC features should be discoverable using this mechanism.

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Nov 1999 14:50:31 -0500

Mark Wahl wrote:
> ...

All of the discussion about message IDs is interesting, but doesn't a
statement like the one or others have suggested really belong in the
LDAP protocol spec. (2251 or its successor)?  I don't see any place in
2251 where it says "Clients SHOULD NOT use a message ID of zero when
sending requests, as zero is reserved for unsolicited notifications." 
The API spec. could make recommendations about how to generate message
IDs that make spoofing more difficult, but even that discussion belongs
in 2251 in my opinion.

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

---

From: Mark Wahl <[email-masked]>
Date: Tue, 16 Nov 1999 14:00:42 -0600

2251 does not restrict clients from using message id 0, since it was really
a client behavior: if your client always does a Bind for its first message,
it would be able to distinguish between a Extended Response and a Bind 
Response.  However to avoid implementors of the C API from introducing a 
subtle problem into their client library, since they don't know what order
clients will make requests, I propose:
 - the C API just state that the values SHOULD be nonzero.., without any 
   requirement that it be a counter
 - we plan that a forthcoming draft on the mapping of LDAP over UDP (CLDAPv3) 
   should include a statement on the security impact of message IDs, and 
   debate the issue of message ID spoofing in that context

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Nov 1999 12:59:10 -0800

At 02:00 PM 11/16/99 -0600, Mark Wahl wrote:
>Response.

The first message a client gets might be an unsolicited notice of
disconnect.

----

---

From: Mark Smith <[email-masked]>
Date: Tue, 16 Nov 1999 17:46:26 -0500

> it would be able to distinguish between a Extended Response and a Bind

Okay, good point (but subtle).

> However to avoid implementors of the C API from introducing a

This sounds like a good approach to me.