[1511] in Kerberos_V5_Development
Re: rlogin -x --> rlogin -noencryption
daemon@ATHENA.MIT.EDU (Sam Hartman)
Wed Aug 7 03:26:02 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: krbdev@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 07 Aug 1996 03:25:51 -0400
In-Reply-To: "Barry Jaspan"'s message of Tue, 6 Aug 1996 12:17:34 -0400
>>>>> ""Barry" == "Barry Jaspan" <bjaspan@MIT.EDU> writes:
"Barry> I think that rlogin be changed so that it encrypts all
"Barry> data by default and has an option to disable encryption.
"Barry> Similarly, krlogind should insist on encryption
"Barry> connections unless it is instructed not to do so.
Sounds like a good idea. I think we should at least consider
a similar change for rsh; it's more problematic because not all rshds
support this, but it would be very confusing from a UI standpoint if
the two programs behave differently.
It's not clear what this means with respec to klogind. The
klogind determines whether it should expect an encrypted connection
based on the presence of the -e flag on the command line. (Remember,
you run twoo different kloginds, one on the encrypted port, one on the
non-encrypted port). If the presence of the -e option doesn't match
the actual state of the connection, things will fail in strange ways,
as the over-the-wire data contains no indication of whether the client
thinks it will encrypt. Thus, unless you have a very bogus
/etc/services on the client side, you won't ever get a non-encrypted
client connecting to the eklogin port.
The only effect I see of changing the default behavior to
assume that you are running klogind on an encrypted port and to require
a flag to go into non-encrypted operation would be to confuse anyone
who has ever installed any version of Kerberos before and to cause
confusion when the klogind running on the non-encrypted port stopped
working as it used to.
Unfortunately, I'm not sure how to deal with this issue
long-term, as it would be nice to have kshd default to requiring
encryption, but it would be nice to have kshd and klogind use similar
interfaces. It's unfortunate that they end up having to do different
things because of the protocol design.
"Barry> Barry
