[265] in Release_7.7_team
telnet points (draft)
daemon@ATHENA.MIT.EDU (Mike Barker)
Thu Jan 19 18:52:06 1995
From: Mike Barker <mbarker@MIT.EDU>
To: release-team@MIT.EDU, jhawk@MIT.EDU
Cc: tytso@MIT.EDU, probe@MIT.EDU
Date: Thu, 19 Jan 1995 18:51:50 EST
Please note that the specific names of the options will be determined
by the implementer to fit with existing command line options. Names
used in this document are only for discussion purposes.
The patches for this are already being processed by rel-eng, so the
proposal is not purely theoretical.
Background:
The main problem being addressed is how to provide the best telnet for
Athena users. This question has been exacerbated by the recent
sniffer attacks and other security concerns.
Basic current provisions:
Telnet has many options. Among these are three that are important to
this discussion.
default--no protection. standard /usr/ucb connection with all traffic
in clear.
-ax available. if cannot get secure connection, falls back without
warning to clear connection.
-safe available. currently equivalent to -ax.
Recommended changes (currently being implemented):
1. provide default which performs autologin and autoencryption if
possible. The default will fallback to clear connection if necessary,
providing clear warning that it is falling back. Also, the default
will clearly indicate that it is a local version of telnet which is
automatically attempting to provide a safe connection.
Rationale: the default should provide a safe connection if possible.
However, it must fallback since there are many hosts which do not
support safe connections. Every fallback should provide a warning.
Further, as a local version of a common program, we should provide an
indication that this behavior is (currently) unusual and specific to
Athena.
2. provide a "-safe" option which performs autologin and
autoencryption if possible. this option will exit with an error if
these are not possible (-fascist). like the default abstraction, this
option will provide an initial message indicating exactly what is
being done.
Rationale: this option has been provided as a convenience to the
users which requests the safest available connection (details of which
may change in the future). this option should not fallback, providing
the user with positive assurance that the connection (if established)
is safe. since this is an abstraction which could be locally
different, it should provide the user with an initial message
indicating what type of service is being established.
3. add "old style" as a functional option (-unsafe)
Rationale: this option is provided for cases where the user really
just wants an unsafe connection. to some extent, this is being
provided for completeness, although it may be useful for applications
of telnet when autologin and encryption would be inappropriate.
4. add "no fallback" as a functional option (-fascist)
Rationale: this option is provided as part of the model of "-safe"
being made up of "smaller" functions. Specifically, instead of the
"encrypted traffic, if not fallback to clear traffic" pattern
currently in use, this option says that if encrypted traffic cannot be
established, the user does not want to proceed.
5. every fallback gives a warning.
Rationale: we consider this a good design principle. while the telnet
traffic provides some indications as to what has happened which may be
understood by some users, we recommend that whenever the software
performs at a different level (or manner) than the normal condition,
an explicit warning be provided to the users.
6. F (forwarding) should not be included.
Rationale: while this option may become effective under Kerberos 5, it
is currently meaningless and we prefer to be honest with our users.
7. Not a new program name.
Rationale: although tempting (e.g. the model of delete/rm), the belief
is that we cannot afford the training time and inevitable failures to
use the new program. I.e., we are trading changes in behavior for the
immediate extra security provided by the new telnet.
Extended explanation of the "initial messages":
Both the default and "-safe" options have initial messages, intended
to provide the user with clear indications of what the local version
is doing. While we expect most users will quickly stop reading the
messages, we believe that they will notice changes in these messages.
I.e., someone going to another site (or coming to MIT from another
site) will notice that the "attempting to open safe connection"
message has disappeared (or appeared).
Proposed provisions:
default-- secure if possible, fallback with warning if not.
initial message describing what local default is.
-safe -- secure connection. exit if unavailable.
initial message describing what local safe is.
-ax -- secure if possible, fallback with warning if not.
-ax"fascist" -- secure. exit if unavailable.
-"unsafe" clear text connection like /usr/ucb/telnet
Please provide corrections or additions to mbarker.
