Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!geof@decwrl.DEC.COM@apolling.UUCP
From: geof@decwrl.DEC.COM@apolling.UUCP (Geof Cooper)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: secure replacements for passwords
Message-ID: <8701122156.AA00076@apolling.imagen.uucp>
Date: Mon, 12-Jan-87 16:56:31 EST
Article-I.D.: apolling.8701122156.AA00076
Posted: Mon Jan 12 16:56:31 1987
Date-Received: Tue, 13-Jan-87 07:08:10 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: imagen!geof@decwrl.DEC.COM
Organization: The ARPA Internet
Lines: 41
Approved: tcp-ip@sri-nic.arpa


 >                                           My theory is that once a TCP
 >      connection is established, it's likely that no one will be able to
 >      break in on it....

I'm not sure you'll have enough secure pieces.  All networks 
traversed by packets that are part of the "secure" tcp connection must
be physically secure.  Otherwise, it is easy to interpose data into a
TCP connection and monitor the result.

For example:
    Monitor the connection and wait until it has been idle for some time
    (around lunch time, so the user is probably not looking at the terminal).
    Then spoof the server into receiving a packet with a particular input
    command in it.  Examine the data that results.  Then spoof a packet that
    causes the server to clear the screen.  Note that the legit TCP client
    will merrily receive all the data.  I wonder if it will get upset that
    the ACK numbers are too high... I'd bet few TCP's would.

    When the legit user returns, he/she will type a bit with no results
    (since the server will ignore those packets).  Eventually things will
    start working again, and he/she will probably just think it a magical
    glitch and not report the problem.

The idea of Needham/Schroeder authentication is the best way to go.  One
option in the scheme was to have the encryption key for the next packet
in this packet, so the above kind of spoofing would be hard (and would
certainly be detected at the legitimate receiver).

Needham/Schroeder doesn't assume that DES is used (as I remember, certainly
there is no need for them to make that assumption).  You can
increase the work factor needed to spoof the system sufficiently by just
XOR-ing passwords into the datastream.  I would think that this would be
"enough security" for a campus environment for the next few years.

- Geof

PS: On further consideration, you could probably get around TCP spoofing by
    just arranging to never leave a connection idle for more than 30 seconds or so.
    If the system dis- and re-connected to the server automatically, the
    users probably wouldn't rebel. - GHC