[5661] in Kerberos
Re: Krb 5.5 Encrypted Login Sessions
daemon@ATHENA.MIT.EDU (warlord@MIT.EDU)
Thu Aug 10 20:07:41 1995
Date: Thu, 10 Aug 1995 20:01:00 -0400
From: warlord@MIT.EDU
To: ramus@nersc.gov (Joe Ramus)
Cc: kerberos@MIT.EDU
In-Reply-To: "[5659] in Kerberos"
> There is no "request to turn on encryption" as part of the
> options negotiation. Therefore, the man in the middle must work
> a lot harder to either prevent encryption or to unscramble the packets.
You're right, there is no negotiation in rlogin. That is one reason
that many people consider rlogin a crock. Telnet, on the other hand,
has lots of negotiation, so telnet client and servers can negotiate
much of how they want to communicate. If you want to communicate in
EBSDIC you can, if both telnet and telnetd support it.
Rlogin, on the other hand, barely has a protocol involved. The reason
you require multiple ports is that there is no way for the rlogind to
realize that encryption was requested vs. a normal, unencrypted
request, because there isn't any sort of protocol to differentiate or
negotiate these options.
> The same method could be used for telnet.
Bzzt. Telnet is a real protocol, with a real standard behind it. As
a result, to add things to the protocol you need to be able to
negotiate options. I dont want to have to run N telnetd programs on N
telnet ports because there are N different types of
authentciation/encryption options available. Rather, I would want to
run a single program on a single port, and have the client/server
negotiate the appropriate encryption.
The problem is that because telnet is a real protocol, this
negotiation has to be standardized. There is no such problem with
rlogin because its a crock.
So, if you want to use encryption, for now, use rlogin. If you want a
real protocol, wait until the telnet encryption options are flushed
out and fixed. You take your pick.
-derek
PS: I do not speak for the MIT Kerberos team; so do not take my
comments as an official MIT response.
