In a message dated 98-12-06 01:13:37 EST, [log in to unmask] writes:

> In <[log in to unmask]> [log in to unmask] writes:
>
>  > PASSWORD ENCRYPTION
>
>  Here I disagree; the *ideal* means of securing a connection between HP3000
>  and a "termulator" (and potentially even a terminal connected via a DTC)
>  would be an SSL type connection between client and HP3000 (or between DTC
>  and HP3000). The SSL library is industry standard, can be very secure,
>  can be implemented easily (merely have the 3000 listen on a new tcp port
for
>  SSL NSVT or SSL telnet connections; this leaves the underlying protocols
>  completely alone/intact). It would certainly be somewhat slower, but the
>  choice could easily be made by the client (or enforced on the host by
>  disabling the non-secure port).

>  Remember that alot of the "secure" information you're likely to send over a
>  network connection isn't just the initial logon... you have application
>  passwords, *data*, maybe you're a system manager or account manager and
>  happen to do a :LISTUSER ;PASS, or print a job stream with passwords of
some
>  type in it....etc. The host isn't gonna know when to go into/out of
"secure"
>  mode...

>  Also, I suspect that SSL could likely be implemented (via an upgrade) in
most
>  modern DTCs, allowng the potential for SSL-encrypted sessions over the
>  "shared wire" portion of the connection between dumb-terminal/serial-
connected
>  pc and the 3000.

Please allow me to disagree with Chris again, hopefully without becoming
disagreeable. Putting encryption below the terminal emulator, in the
communications channel, as an SSL-like process, has several significant
disadvantages, exactly as Chris says:

     o  It will/might be slow.

     o  It would constrained to TCP/IP communications only.

     o  It would (might, if any cared to do so) require firmware upgrades of
"modern" DTCs. In contrast, if encryption/decryption is done in the terminal
emulator proper, and not in the transport process, the transmitted text will
be encrypted end-to-end and pass through whatever form of communications exist
(direct connect, dialup, ns/vt, telnet, etc), without regard.

     o  It is a fixed algorithm. While SSL is a current industry standard,
it's only one standard. If I were to predict the future, there will an
evolution of what is and what is not considered "secure" at any particular
moment. While compression algorithms are likely to be stable on the long-term,
I doubt that that will true for encryption algorithms. Some sense of easy
maintainability (i.e., addition of new, more powerful encryption algorithms)
over the long term should be given serious thought from the outset in the
design. It's for this reason that I proposed adding a new terminal
capabilities status response sequence, "Esc*s-5^", so that the terminal
emulator could inform MPE which encryption algorithms it supports and let MPE
pick the most powerful routine supported at both ends.

Under any circumstance, it is difficult to see how SSL could be implemented
without having status words in the emulator available to reflect the
emulator's capabilities, thus some significant part of the encryption process
must be done very much as earlier outlined. SSL is essentially no more than
one choice of encryption algorithm.

Nor are the disadvantages Chris points out real regarding having encryption be
done at a level higher than the communications channel. Encryption could be
turned on for just the period of password transfers, in either MPE or an
applications program, or it could be turned on for the entire session dialog,
or it could be turned on and off for significant periods of time, just as
individual web pages turn on and off SSL now.

In any case, whether encryption is performed in just the telnet layer, or in
an SSL-like layer above telnet, or in the emulator proper, regardless of the
form of the communication medium, the current crop of terminal emulators will
have to be modified to negotiate the encryption process with MPE -- and
whatever is ultimately decided has to be the result of a cooperative
discussion between HP and the emulator manufacturers.

That alone, unfortunately, will always be a slow process. No one can simply
decide to do this on their own.

Wirt Atmar