[1517] in Kerberos_V5_Development
Re: rlogin -x --> rlogin -noencryption
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Aug 7 19:07:19 1996
To: Sam Hartman <hartmans@MIT.EDU>
Cc: "Barry Jaspan" <bjaspan@MIT.EDU>, krbdev@MIT.EDU
From: Ken Raeburn <raeburn@cygnus.com>
Date: 07 Aug 1996 19:06:35 -0400
In-Reply-To: Sam Hartman's message of 07 Aug 1996 03:25:51 -0400
Sam Hartman <hartmans@MIT.EDU> writes:
> >>>>> ""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.
We've already got client-side changes at Cygnus to make the default be
determined by an option in the krb5.conf file, with command-line
options to override either way. (We also handle defaulting of ticket
forwarding that way.)
The server side would continue to work fine as it is -- I don't see
any strong reason to change the command-line options. If you change
the default, non-encrypted sessions break unless inetd.conf is
changed. If you leave it as is, everything is fine. I wouldn't have
a problem with adding a new option that explicitly indicates a
non-encrypted session, but I think the default for beta7 should be
non-encrypted (and maybe log a warning, if you want to change the
default for the Official Non-Beta Release of krb5.)
I don't think this sort of change is necessary for beta 7, though;
shouldn't the priority be on getting that out the door?
> 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.
I wasn't aware of that. Still, as long as the user can override --
and if we can produce an intelligible error message -- it may still
work okay.
