[13291] in Athena Bugs
Re: telnet
daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Mar 6 15:42:12 1995
Date: Mon, 6 Mar 1995 15:42:09 -0500
To: Chris Shabsin <shabby@MIT.EDU>
Cc: bugs@MIT.EDU, brlewis@MIT.EDU, tytso@MIT.EDU
In-Reply-To: "[13290] in Athena Bugs"
From: John Hawkinson <jhawk@MIT.EDU>
Shabby writes:
> It's impossible to get a telnet connection that is encrypted but
> unauthenticated, as near as I can tell.
This is largely correct. It is, however, not an implementational
deficieny, but it is a protocol bug/issue.
It rests upon the fact that you cannot obtain a telnet connection with
encryption without obtaining one with authentication, and the
telnet authentication option is overloaded to mean two things:
1) Exchange authentication information to prove who I am
2) Perform "autologin" as the person who provided the auth
data.
It is possible to reconfigure both of these pieces of behavior
in an implementational-specific fashion on the server side, as
evidenced by ``telnetd -a off''.
My understand is that the RFCs defining the behavior of kerberos
authenticated telnet are at fault here (RFC1411 and RFC1416) and thus
the fault rests with the now-defunct IETF Telnet working group.
Just after IAP when I was reexamining telnet, I seriously considered
implementing the behavior you requested, and decided that doing so
without standardization would be poor--I was prompted by the (IMHO
poor) idea of using ``telnetd -a off'' in the default inetd.conf files
for Athena workstations.
As for the status of the IETF telnet effort, the Toronto IETF in July,
I believe that Ted Ts'o agreed to deal with a few of the problems with
telnet encryption options. I never learned what became of this
(presumably something happened at the December IETF in San Jose), but
I think that you probably ought to ask Ted about this if you are
seriously interested in following up.
Lastly, it should be noted that an implementation option could be
added to telnet and login.krb such that if telnet were invoked with
particular options, it would accept kerberized authentication, convey
the information to login.krb that such authentication was received
(through the use of Yet Another Command Line Option), and login.krb
would prompt for a password, (all this behavior is the norm for
``telnetd -a off'') and login.krb would then accept a null password
(i.e. hitting return) as meaning you wished to rely upon the
authentication accepted by telnetd, OR login.krb would accept a real
password and attempt to re-authenticate, thus getting you
tickets. This solution is ugly and kludgy, but certainly seems
convenient.
--jhawk (who has had it up to HERE with telnet for a while...)
