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

[Harald Tveit Alvestrand <Harald@Alvestrand.no>]

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
Harald.Alvestrand@maxware.no