[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: C API: minor comments



Title: RE: C API: minor comments


> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:kurt@boolean.net]
> Sent: Monday, November 15, 1999 3:11 PM
> To: Mark Wahl
> Cc: Paul Leach (Exchange); mcs@netscape.com; howes@yahoo.com; Andy
> Herron (Exchange); Anoop Anantha (Exchange); kurt@OpenLDAP.Org;
> ietf-ldapext@netscape.com
> Subject: Re: C API: minor comments
>
>
> At 04:49 PM 11/15/99 -0600, Mark Wahl wrote:
> >
> >> > 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.
>
> 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