Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!MIT-MULTICS.ARPA!JSLove From: JSLove@MIT-MULTICS.ARPA.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Re: secure replacements for passwords Message-ID: <870301054108.921938@MIT-MULTICS.ARPA> Date: Sun, 1-Mar-87 00:41:00 EST Article-I.D.: MIT-MULT.870301054108.921938 Posted: Sun Mar 1 00:41:00 1987 Date-Received: Sun, 1-Mar-87 16:48:17 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 91 Approved: tcp-ip@sri-nic.arpa Date: 18 January 1987 15:57 est From: The Matt Crawford of net.* Subject: Re: secure replacements for passwords J. Spencer Love writes: ) 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 is 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. Nope, RFC-793 says "If the ACK acks something not yet sent (SEG.ACK > SND.NXT) then send an ACK, drop the segment, and return. Thank you for pointing this out. I'm sorry that this reply is so delayed. The Multics TCP does, in fact, behave as I claimed. I have examined RFC-793, and the sentence which Matt Crawford quoted is on page 72 (page 2-256 of the DDN PROTOCOL HANDBOOK). This deals with the ESTABLISHED state. In the pre-ESTABLISHED states (LISTEN, SYN-SENT and SYN-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