[13288] in Athena Bugs
telnet -K/-safe options interacting poorly...
daemon@ATHENA.MIT.EDU (pshuang@MIT.EDU)
Sun Mar 5 20:14:50 1995
From: pshuang@MIT.EDU
Date: Sun, 5 Mar 95 20:14:42 -0500
Reply-To: suggest@MIT.EDU
To: suggest@MIT.EDU
Cc: bugs@MIT.EDU
Summary: the -safe option does *NOT* guarantee the user that if he or
she is allowed to proceed that the connection is indeed safe; the -K
option turns off the informative and warning messages about whether
authentication and encryption have been established; telnet's "status"
and "encrypt status" appear to not accurately display encryption
status (claiming the connection is encrypted when it is not).
---------------- Begin OLC transaction replay
Log Initiated for user Ping Huang (pshuang@CARTOON.MIT.EDU [0]).
[Sun 05-Mar-95 6:56pm]
Topic: dialup
Question:
[This could have gone under the accounts topic, too, I suppose.]
I notice inconsistent behavior in the latest PATCH release to Athena.
According to the man pages, -K prevents telnet from sending your
username over for you (i.e., disables auto-login). However, it
appears that it also disables the warning messages about connecting to
a machine which does not support authentication and/or encryption.
I thought I might sanity check my understanding before I run sendbug.
-------- cut here --------
athena% hostname
cartoon
athena% telnet crl.com
...including Athena's default telnet options: "-ax"
Trying 165.113.1.12...
Connected to crl.com.
Escape character is '^]'.
[ Warning: Server does not support authentication. ]
[ Warning: Server does not support encryption. ]
SunOS UNIX (crl)
login:
-------- cut here --------
athena% hostname
cartoon
athena% telnet -K crl.com
Trying 165.113.1.12...
Connected to crl.com.
Escape character is '^]'.
SunOS UNIX (crl)
login:
-------- cut here --------
Machine info:
Processor: DECstation Maxine
Display : Color DS Maxine
Memory : 0x1262000 user; 0x1800000 (24 M) total
___________________________________________________________
--- Question grabbed by sipb_volunteer hartmans@TERTIUS.MIT.EDU [0].
[Sun 05-Mar-95 6:58pm]
*** Reply from sipb_volunteer hartmans@TERTIUS.MIT.EDU [0].
[Sun 05-Mar-95 7:11pm]
Greetings; I am a student Athena developer and I paid fairly
close attension to the discussions about Telnet; these discussions
were on the suggestions meeting, rel-eng meeting, and to a certain
extent in private mail.
Anyway, because of the way Kerberos works, it is impossible to
have an encrypted connection to a host without sending your user name.
That is, the functionality of the -u and -k flag cannot be different
at this time.
It is not clear that what you describe is a bug. However, it
is clear that the documentation or behavior should be changed. If you
would like to pursue this issue, feel free to send mail to
suggest@mit.edu including what behavior you observe, what you think
the problem with this behavior (or the documentation is), what you
think the solution should be, and why. This way, you can discuss the
issue with the developers and we can have Telnet's behavior be
intuitive and secure.
--- Topic changed from 'dialup' to 'networks' by sipb_volunteer hartmans.
[Sun 05-Mar-95 7:18pm]
*** Reply from user pshuang@CARTOON.MIT.EDU [0].
[Sun 05-Mar-95 7:27pm]
I do very much think that the behavior with "-safe -K" is a bug, since
the change to "-safe" in the PATCH release was purported to ensure
that if the user ever put "-safe" on the command line, they were
*GUARANTEED* that their connection was secured, or telnet would refuse
to let them make the connection in the first place.
As for the assertion that an encrypted connection cannot be
established without an username, I counter-offer with this transcript.
Either the assertion or telnet's output is in error.
-------- cut here --------
athena% hostname
cartoon
athena% telnet -safe -K express.dialup
...including options requested by -safe: "-axN"
Trying 18.71.0.53...
Connected to express.dialup.MIT.EDU.
Escape character is '^]'.
MIT Athena (al-forno/Ultrix) (ttyp6)
login:
telnet> status
Connected to cartoon.mit.edu.
Operating in single character mode
Catching signals locally
Remote character echo
Local flow control
Currently encrypting output with DES_CFB64
Currently decrypting input with DES_CFB64
Escape character is '^]'.
telnet> encrypt status
Session key is 253 98 182 134 241 103 97 193
Currently encrypting output with DES_CFB64
Currently decrypting input with DES_CFB64
-------- cut here --------
*** Reply from sipb_volunteer hartmans@TERTIUS.MIT.EDU [0].
[Sun 05-Mar-95 7:57pm]
I have examined an options trace from telnet -safe -K. What
is happening is that the client is offering to do encryption, and the
server accepts. Then, the server requests the client to do
authentication; since -K is supplied, the client refuses. The client
and server exchange supported encryption protocols and continue with
other options negotiation. All fine, except for the minor detail that
the client and server never actually got around to exchanging keys or
starting the encryption.
However, with telnet -safe (without -K), the client and server
exchange a Kerberos authenticator, challenge and response. After this
is done, an encryption start option is sent.
In my opinion, this behavior is very misleading and is very
much a bug, especially because encrypt status makes the user think the
connection is encrypted.
In response to your earlier statement, I agree that it would
be a bug for `telnet -safe -K crl.com' to connect you without
encryption. However, if you look back in your earlier message, you
typed `telnet -K crl.com'. Normally, this gives a warning because the
encryption fails, but this warning is suppressed by the -K option. I
agree something is wrong with this example, but I'm not sure if the
problem is in the behavior of telnet or in the documentation. The
reason I suggested mailing to suggest@mit.edu instead of bugs@mit.edu
is that the bugs database makes it difficult to hold discussions on
what the proper fix to a problem is. The solution to the problems you
have brought up is not clear to me, nor do I think it will be clear to
the developers responsible for implementing it, so a discussion of
possible solutions and their advantages and disadvantages is in order.
---------------- End OLC transaction replay
