Re: secure replacements for passwords


J. Spencer Love (JSLove@MIT-MULTICS.ARPA)
Sun, 1 Mar 87 00:41 EST


BAD MSG:
state. In the pre-ESTABLISHED states (LISTEN, SYN-SENT and
YN-RECEIVED), the specification directs the implementor to form a RST
packet based on the invalid acknowledgement. Thus, the Multics
implementation's behavior is conformant until the connection is
established, and deviant thereafter.

Does anyone know what the specifiers had in mind when they made this
distinction? The rest of this message attempts to explain my reasons
for believing that the specification is wrong here and should be
changed.

If someone attempts to spoof the connection, they can do so by
monitoring the connection and inserting a packet. This packet might
contain commands (via the TELNET server), spurious mail, or faked output
(back to the user TELNET). Because packets routinely come from gateways
which are not the IP header source, it is difficult to detect this
spoofing by examining the lower layer's packet source.

There are two cases. In the "hard" case, the spoofer has corrupted
network routing, so that no packets are exchanged between the original
connection endpoints. The spoofer can insert itself into the
connection, completely concealing its presence, or permit one side of
the connection to time out, replacing it to the other side of the
connection. Hopefully, this type of spoofing can be prevented by other
means.

In the "easy" case, the connection routing is not disrupted. The bogus
packet is merely inserted into the stream. The receiver of the bogus
packet will issue an acknowledgement which will get back to the other
end of the connection. If we are lucky, this packet will appear to
acknowledge something which hasn't yet been sent. If it *has* been
sent, then the chance of the bogus packet's being accepted is reduced,
unless routing has also been corrupted. If routing has been corrupted
in the direction that the bogus packet's acknowledgement will travel,
then this is effectively the same as the "hard" case.

I can't think of a situation where a "precognitive" acknowledgement is
valid. If one arrives, it indicates either that a spoof attempt has
been made, or that a packet has long outlived its TTL and emerged from
some network backwater like some kind of glacier-preserved SF creature.
The chance that such an anachronism will also pass the sequence number
check is hopefully small, but certain operating systems which we all
know are very repetitious about selecting port and sequence numbers.

The receiver of the precognitive acknowledgement should send a RST
packet. Ideally, it should also refrain from sending data up to the
precognition point for awhile (some function of RTT and TTL), but that
is probably too much to ask. It should also log the precognitive ACK as
a possible spoof attempt.

If the precognitive ACK really emerged from the glacier, then (ignoring
race conditions), the RST packet which it elicits will fail the sequence
number test at the other end of the connection and is thus harmless. If
routing has been corrupted in the direction the RST travels, at least
the spoof has been detected and logged at one end so that
troubleshooting can find it later. If the RST gets through, it will
abort the spoofed connection and hopefully minimize the damage. If the
RST packet carries an "explanation" in its otherwise unused data field,
then this also can be logged at the receiving end so that both ends of
the connection have a record of the spoof.

The likelihood of having normal service clobbered by this RST is low.
The likelihood of a spoof is hard to estimate, but the protocol should
act to limit, as much as possible, the effects of spoofing, and to
detect such attempts, especially when no extra work is involved.

With this in mind, I don't plan to change Multics to conform to the
specification in this area, although I would be interested in and would
act upon a convincing refutation.
                                        -- Spencer Love



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:43 GMT