Subject: Details on TCP sequence numbers (RE: C API: minor comments)

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 16 Nov 1999 08:08:32 -0500

At 18:07 15.11.99 -0800, Paul Leach (Exchange) wrote:

> > 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.
The particular attack being guarded against by TCP random initial sequence 
numbers is described in RFC 1948; it lets an attacker set up a connection 
from an IP address other than his own even when he is not able to listen to 
the packets coming back, so as to be able to (for instance) get a command 
executed over the Berkeley Remote Shell interface.

It only works for impersonating a client, not impersonating a server.

For the attack to be successful, it depends on:
- Trust being extended on the basis of source IP address
- Initial sequence numbers being badly chosen

It does not seem particularly relevant to LDAP, since:

- LDAP does not rely on IP addresses for authentication (shouldn't, anyway!)
- Both strong authentication and secure transport for anonymous clients are 
available
   in LDAP (you can use TLS with anon clients just fine - see 99% of the 
HTTPS out there)
- An attack that depends on faking message IDs without the ability to 
listen in on the
   channel requires TCP transport hijacking, not just the RFC 1948 attack, 
since one
   needs a legitimate user to get past the authentication phase first.
   This is a lot tougher than the RFC 1948 attack; I'd say it's impossible 
without being
   able to listen to at least one direction of traffic, and then LDAP 
message IDs are
   available anyway.

Security: the devil is in the details....

                     Harald A

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

---

From: "Paul Leach (Exchange)" <[email-masked]>
Date: Tue, 16 Nov 1999 09:49:34 -0800

As I said before, I was concerned in the LDAP/UDP case -- not yet a
standard, but there was support for progressing it at the last IETF.

In that case, and for anonymous access, and assuming that the attacker has a
good idea what requests are going to look like, then it is possible to
inject bogus responses, or even bogus requests, without being able to see
the traffic. The TCP example was intended to be analagous, not identical --
I was using it as an illustration of the technique -- clearly attackers have
a much better idea of what SYN packets look like than what the first LDAP
request will look like.

Using random initial sequence numbers seems a small price to pay to avoid
worries. It is very hard to predict the consequences of having such a
vulnerability.

Paul

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 16 Nov 1999 19:55:53 -0500

At 09:49 16.11.99 -0800, Paul Leach (Exchange) wrote:

>In that case, and for anonymous access, and assuming that the attacker has 
>a good idea what requests are going to look like, then it is possible to 
>the traffic. The TCP example was intended to be analagous, not identical 
>-- I was using it as an illustration of the technique -- clearly attackers 
>have a much better idea of what SYN packets look like than what the first 
>LDAP request will look like.

Assuming that there will be no authentication in CLDAP, and that it will be 
used to access or change non-public information?

>worries. It is very hard to predict the consequences of having such a 

For unauthenticated CLDAP - yes.

I still say it does not matter in the present batch of specs.

                       Harald