Subject: RE: C API: minor comments

From: "Anoop Anantha (Exchange)" <[email-masked]>
Date: Mon, 15 Nov 1999 16:29:33 -0800

1] The description for LDAP_LOCAL_ERROR seems to suggest that no further
operations can be performed using the library since it is not in a
consistent state. I understand this is implementation specific but some
libraries might return this on a per operation basis and recover fully for
subsequent operations. I suggest it reads (if we decide to add
descriptions), for lack of a better description,

 - LDAP_LOCAL_ERROR (0x52)
	A generic error occured on this operation.

2] It might also help if we clarify that an application looking for
LDAP_RES_UNSOLICITED messages MAY get back messages of type
LDAP_RES_EXTENDED.

3] A client library MUST toss unsolicited responses with non-zero
messageIds. For unsolicited notifications with zero messageId, I would
suggest the default behavior be to toss them unless the app has explicitly
asked for them. We could provide an option to queue up these notifications
for applications which need them. If we don't do this, simple applications
which know nothing about unsolicited notifications will not process them and
the notifications may continue to queue up until the client runs out of
memory.

-Anoop Anantha

-----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.  

In section 13 I suggest we add after the first paragraph.

ldap_result() can also be used to obtain unsolicited notifications from
the server.  

In section 15 please note that a search can return extended responses
as well as a search result done, and so these belong in the chain.

I think it would be helpful if section 10 described what the meanings
of errors 0x51 through 0x61 are.  Of these only LDAP_PARAM_ERROR is
actually used in this draft:

 - LDAP_SERVER_DOWN (0x51)
	The client library could not send the request to the server as the
	connection has been lost.  The client can use ldap_result to obtain
	any outstanding results left on this connection, but cannot issue
	any new requests.  Once all the results have been obtained the
client
	SHOULD use ldap_unbind() to complete the disconnection process.

 - LDAP_LOCAL_ERROR (0x52)
	The client library is in an inconsistent state.  

 - LDAP_ENCODING_ERROR (0x53)
	
 - LDAP_DECODING_ERROR (0x54)

 - LDAP_TIMEOUT (0x55)
	Return code from ldap_search_st().

 - LDAP_AUTH_UNKNOWN (0x56)
	Unsupported authmethod flag to ldap_bind() or ldap_bind_s().

 - LDAP_FILTER_ERROR (0x57)
	Filter parameter to search is not correctly written.

 - LDAP_USER_CANCELLED (0x58)
	Reserved.

 - LDAP_PARAM_ERROR (0x59)

 - LDAP_NO_MEMORY (0x5a)

 - LDAP_CONNECT_ERROR (0x5b)

 - LDAP_NOT_SUPPORTED (0x5c)

 - LDAP_CONTROL_NOT_FOUND (0x5d)
	Used by extensions to this API.

 - LDAP_NO_RESULTS_RETURNED (0x5e)
	Reserved.

 - LDAP_MORE_RESULTS_TO_RETURN (0x5f)
	Reserved.

 - LDAP_CLIENT_LOOP (0x60)
	Reserved.

 - LDAP_REFERRAL_LIMIT_EXCEEDED (0x61)

Open question on unsolicited notification:

 1. Do unsolicited notifications queue up in the client library until the
 client asks for them with ldap_result() or an ldap_unbind() occurs?  On
 a related note, what does the client library do if it receives a response
 for which there is no matching request?  

Mark Wahl, Directory Product Architect
Innosoft International, Inc.

---

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

> From: Kurt D. Zeilenga [mailto:[email-masked]]
> Sent: Monday, November 15, 1999 3:11 PM
> To: Mark Wahl
> Cc: Paul Leach (Exchange); [email-masked]; [email-masked]; Andy
> Herron (Exchange); Anoop Anantha (Exchange); [email-masked];
> [email-masked]
> Subject: Re: C API: minor comments
> 
> 
> At 04:49 PM 11/15/99 -0600, Mark Wahl wrote:
> >
> >> 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.
> 
> Replies and Responses can just as easily be spoofed if the IDs are not
> predictable.

How? If the attacker does not know what ID is being used, and chooses the
wrong one, then it will be detectable and the spoofed message can be
discarded.

> 
> >> How about suggesting that requests be even and unsolicited 
> notifications be
> >> odd?
> >
> >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.
> 
> 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.

I would suggest:

	Typical API implementations start with a random number between 1 and
2147483647, and increment it for each request.
> 
> Note: the last sentence is consistent with RFC2251.

If your proposal is consistent with 2251, then mine should be too.

> 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.

Use of random initial sequence numbers has been known for a long time to
improve the security of TCP against session hijacking attacks, without
requiring the use of a secure transport, which will be unavailable for
anonymous connections. I see no reason not to recommend it here.

Paul

---

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

At 06:07 PM 11/15/99 -0800, Paul Leach (Exchange) wrote: 
> How? If the attacker does not know what ID is being used,
> and chooses the wrong one, then it will be detectable and
> the spoofed message can be discarded.

Well, if she spoofy results to a client, you need to know
the message id used (and other specifics of the request).
This assumes you can read what the client is sending and
match your responses.

If she is spoofy the server, then she only needs to pick
an ID to which is not outstanding.  Zero or any recently
completed message id are all very unlikely to conflict
with future requests.

And if you can spoof, ie: insert/remove bytes from the
stream, then frankly, the spoofer can translate around
any message ID conflicts between what it's doing and
what the client/server are doing.

It's my opinion that use of a counter creates no significant
security risk.  It's my opinion that initializing the counter
to a random value does not improve security.  It's my opinion
that use of random sequence would weaken security (because
of added implementation complexity).

>If your proposal is consistent with 2251, then mine should be too.

I quote from RFC2251: "Typical clients increment a counter for each
request."

Your statement is false.  It's Atypical for LDAP implementations to
"start with a random number between 1 and 2147483647."

Those who worry about being spoofed should be deploying TLS and other
security transport technologies.

>Use of random initial sequence numbers has been known for a long time to >improve the security of TCP against session hijacking attacks, without >requiring the use of a secure transport, which will be unavailable for >anonymous connections. I see no reason not to recommend it here.

TCP sequence numbers and LDAP messageIDs are apples and oranges.
In particular, LDAP messageIDs are not necessilary sequenced.

Kurt

---

From: "Anoop Anantha (Exchange)" <[email-masked]>
Date: Tue, 16 Nov 1999 13:40:05 -0800

We might think that unsolicited notifications are minimal under usual
conditions. But consider a server which sends notices of idle disconnection
every 10 mins into an idle session to clients written using synchronous
APIs. These messages will continue to pile up over a period of time because
the client has no way of processing these. This is just one example.
Moreover, since we don't know how unsolicited notifications will be used in
future, a memory leak, however small it may seem, is problematic in the long
run.

Either we should have a way for synchronous APIs to get at these
notifications (not elegant) or we should have the client library toss these
unless the app explicitly asks for it.

-Anoop

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, November 16, 1999 12:52 PM
To: Mark Smith
Cc: Anoop Anantha (Exchange); 'Mark Wahl'; [email-masked]; Andy Herron
(Exchange); [email-masked]; [email-masked]
Subject: Re: C API: minor comments

Mark Smith wrote:
> Ouch.

I guess I should have put a :-) on that comment.  :-)

> But I agree that they should be queued by default.  Do we really
> expect so many unsolicited notifications to be sent so as to overwhelm a
> client? 

No.  I hope that unsolicited notifications would be minimal under
usual conditions.  The only time I could think that a client
could get overwhelmed is that if it enabled some feature which
caused lots of unsolicited notifications (such as enabling
some sort of monitoring) to be sent.  Of course, clients enabling
such features should be expecting the notifications.  Also, note,
with the introduction of ExtendedPartialResponse, such (ab)uses
of unsolicited notification might never be created.

> The only one that is defined is the notice of disconnection
> from 2251.  Are there any other examples in practice?

Not that I am aware of.

Kurt

---

From: "Anoop Anantha (Exchange)" <[email-masked]>
Date: Tue, 16 Nov 1999 11:28:53 -0800

>If the client always uses non-zero messageIDs in requests,
>how could it get a solicited extended response of message
>with message id of zero?

It can't. It may however, get *unsolicited* extended responses with
messageId 0. Currently, most clients don't expect this kind of response.
Hence, it is worthy to make a mention of it.

>Yes.  This should teach applications not to implicitly
>ignore unsolicited notifications.

Consider a simple application written using only the synchronous APIs
(typical case). How does the app know that the server is even sending
unsolicited notifications? It won't. This may cause the client library to
run out of memory due to queued up notifications. This is just one of the
reasons, IMO, for the default behavior of tossing notifications unless the
app sets an option to receive them.

-Anoop Anantha

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Monday, November 15, 1999 7:07 PM
To: Anoop Anantha (Exchange)
Cc: 'Mark Wahl'; [email-masked]; [email-masked]; Andy Herron
(Exchange); [email-masked]; [email-masked]
Subject: RE: C API: minor comments

>LDAP_RES_UNSOLICITED messages MAY get back messages of type

If the client always uses non-zero messageIDs in requests,
how could it get a solicited extended response of message
with message id of zero?

>messageIds.

Though this would hide the existance of such messages from the
application (not allowing it to report the problem to the user),
it is likely a sane practice (as being malformed messages).

>For unsolicited notifications with zero messageId, I would
>asked for them.

In a non-threaded environment, the application may use polling of
responses (using ldap_result) to implement multiplexing.  I'd
don't think unsolicited notifications should be tossed as this
would disallow polling for them.  I also think it unwise to
encourage unsolicited notifications from being ignored.  If the
app chooses to toss them, that's their choice.  But the API,
I believe should provide them UNLESS the app explicitly
says to toss them (using some client control or option).

>We could provide an option to queue up these notifications
>for applications which need them.

I prefer to add an option to disable queuing of unsolited notifications.
The default, IMO, should be to queue them.

>If we don't do this, simple applications

Yes.  This should teach applications not to implicitly
ignore unsolicited notifications.

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

---

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

At 11:28 AM 11/16/99 -0800, Anoop Anantha (Exchange) wrote:
>unsolicited notifications?

It should realize that an unsolicited notification may occur while
waiting for the results.  A client which blocks forever waiting for
results of a specific result is likely to do just that, block forever.

>It won't. This may cause the client library to

It seems to me that sync routines are only generally useful
in multithreaded environments... as the existance of unsolicited
responses may require multiplexing even when operations are
serialized.

----