Re: Would an encrypted tunnel solve the SeqNo guessing attack?

[tdarcos () access digex net (Paul Robinson)]

On Thu, 26 Jan 1995, Bennett Todd wrote:

> I'm not keen on the idea of people grabbing my telnet session away from me
> and making free with it. I'm resigned to the notion that they can steal
> it; I'd like to make it useless to them once they've got it.
>
> Suppose I took term (a multiplexing, compressing, error-correcting serial
> tunnel program) and added encryption, and rigged that to be my login shell.
> I'd log in to the computer, and after my S/Key prompt it'd fire up an
> encrypted term. I don't see any way some could burgle in through that.
>
> Have I missed something fundamental here? Or would this work?

If he has to have something on his end to connect to that program that 
would require a serial number, sequence number or something else that 
would be difficult to guess, probably.

But then again, it requires some specialized service capabilities from 
the caller's end.  And if it's a pain to use, or denies people some means 
of using their favorite terminal program, it may either not get used or 
not get used very much.

For example, I use Telemate, which I have used for more than 3 years 
because of its powerful multiprocessing capabilty, including built in 
text editor, file viewer, DOS shell and internal Zmodem.  Has all of the 
top features including cut and paste in all venues (cut and paste to and 
from the editor and screen, cut from the file vewer to the screen or the 
editor), a programmable script language, a script learn facility, 
emulation for VT100, ANSI and the emulation code can be customized for 
other terminal types, ability to program allmost all ALT and Function key 
combinations for macro capability, and other features, plus the ability 
to multiprogram, where I can Zmodem download on the screen, then read a 
file of downloaded messages in another window while the program continues 
the download (or upload).  This is all done from MS DOS, *not* using any 
special multitasking programs.  

I probably tried in excess of 20 different terminal programs before I
found this one, and while the program gives 30 days to decide to register
it, I didn't even wait two weeks before sending in a check: the program
was too good *not* to pay for it. 

Point being that I have become accustomed to this program, and its 
excellent features increase my online productivity by a significant 
amount.  When I use another terminal program, it *hurts* because I lose a 
significant functionality which I have in Telemate.

Telemate will, however, talk through a fossil driver or INT 14 on the PC, 
and thus can be used through a "software shim" for unusual hardware *or 
unusual communications conditions*.

This is probably true of other people using programs on other machines 
and need this sort of capability. 

I therefore propose that those of us who are interested consider creating 
a standard for a traffic encryption or traffic management protocol (TMP) so 
that all I have to do, if I'm going to log into a TMP secured host, is 
load a TSR ahead of my terminal program, and the TSR only reacts if it 
receives a "begin TMP secured protocol" sequence.  The terminal program 
I'm using and the recipient software at the other end need no 
modification, and they just talk to the "software shims" at their end, 
while the "shims" send encrypted traffic between one another.  

If the standard is published, not black box and easily implementable, we 
eliminate the "security through obscurity" nonexistent protections, and 
thus create a standard so anyone can perform encrypted connections and 
not have to worry about the innards; just fire up the software and let it 
take care of the underlying protocol.

Anyone interested in working on this, write me back.

--
Ask me about Listmgr - the first PC-Based mailing list manager for E-Mail.
Reports on Security Problems: To Subscribe write PROBLEMS-REQUEST () TDR COM
Paul Robinson - paul () tdr com / tdarcos () MCIMail com / tdarcos () access digex net
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy () psg com>