Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!ucbvax!MIT-MULTICS.ARPA!JSLove
From: JSLove@MIT-MULTICS.ARPA.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: secure replacements for passwords
Message-ID: <870113143008.200363@MIT-MULTICS.ARPA>
Date: Tue, 13-Jan-87 09:30:00 EST
Article-I.D.: MIT-MULT.870113143008.200363
Posted: Tue Jan 13 09:30:00 1987
Date-Received: Tue, 13-Jan-87 19:23:41 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 35
Approved: tcp-ip@sri-nic.arpa

I don't know about your TCP, but the Multics TCP will send a RST
immediately if it receives a packet with an ACK that it`s too high.  I
believe that this is clearly spelled out in the specification, but I am
at home and don't have the specification handy.

To prevent this, your penetrator must break network routing (e.g., using
ARP) to prevent the acknowledgements from reaching the workstation or
the RSTs they provoke from getting back to the server.  If you don't
mind breaking the connection, any damage you can do with a single packet
is perfectly possible.

I don't think most TCPs would give out any indication of why the
connection was broken, either on the scren or in a debugging log.  An
workstation in debug mode might note that an out-of-sequence
acknowledgement was received, but the server would only note that the
user had aborted the connection.  If you really have control of network
routing, it would be interesting to see if you could insert the
penetrator between the workstation and server, effectively splitting an
existing session into two sessions with the penetrator in the middle.
The potential for mischief would be awesome.

Receiving a packet which contains out-of-sequence acknowledgement should
probably ring alarm bells.  Even out-of-sequence packets which don't
contain acknowledgement (and thus must be SYN packets) are illegal, but
they probably indicate that the other end has crashed or a TTL anomaly,
rather than a penetration attempt.

Something else that might help is putting reasons for aborts into RST
packets as data, and having the receiving TCP log the abort reason.
Then there would be a record of the break-in at both ends of the
connection.  I believe that there are TCPs which implement this, but
have no idea which ones.  It certainly isn't in the spec.  (This could
be circumvented by having the penetrator abort the connection, but
unless routing is subverted, this gives too short a window to do much
other mischief.)