[6521] in Kerberos
Re: Request for input: proposed krshd and krlogind option reorganization
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Jan 23 17:16:55 1996
To: "Barry Jaspan" <bjaspan@bbnplanet.com>
Cc: hartmans@MIT.EDU (Sam Hartman), kerberos@MIT.EDU
From: hartmans@MIT.EDU (Sam Hartman)
Date: 23 Jan 1996 16:54:59 -0500
In-Reply-To: "Barry Jaspan"'s message of Tue, 23 Jan 96 11:59:03 EST
>>>>> "Barry" == Barry Jaspan <bjaspan@bbnplanet.com> writes:
Barry> Sam,
Barry> Thanks for tackling this messy collection of issues.
Barry> First, there is serious discussion of dropping
Barry> support for .rhosts files in krlogind and
Barry> krshd... [proposal to] remove support for requiring that a
Barry> user present both valid Kerberos authentication and rhosts
Barry> authentication in the same session (-K -R under the current
Barry> options).
Barry> I suggest removing all support .rhosts entirely, including
Barry> the -r option you propose below. There is no reason to
Barry> provide .rhosts functionality in a Kerberos rlogind. If a
Barry> site wishes to support Kerberos authentication and rhosts
Barry> authentication (which is pretty silly), it can simply run
Barry> their vendor's rlogind on the standard port and krlogind on
Barry> the klogin port.
The rhosts support in krlogind is somewhat different than in
the vendor rlogind. However, I think it's *more* broken than the
normal krlogind so I probably will punt it at the first sign of
difficulty unless someone gives an example of when it is useful.
Barry> So, we propose the following options to select
Barry> encryption and authentication for krlogind and krshd:
Barry> - -e: enable encryption on krlogind, require it on krshd
Barry> Why the difference between krlogind and krshd? That will
Barry> be confusing. If you want one to allow and another to
Barry> insist, use something like -e and -E.
This is more of a semantic difference than an actual
difference in function. The eklogind runs on a different port than
the normal klogind, and the krlogind protocol doesn't specify whether
the client wants encryption or not; both the server and client have to
be told at startup time whether to enable encryption or not. However,
the krshd sends information about whether to enable encryption
in-band, so it is always enabled, and the client chooses to activate
it at startup time.
In other words, it won't be confusing. The -e option to
krlogind tells it that all clients that connect to this port will be
encrypted clients. The -e option to krshd tells krshd that it should
refuse to connect with any non-encrypted clients that connect to it.
Barry> - -r: Accept .rhosts authentication
Barry> IMHO, punt entirely, as described above.
Barry> The -4, -5, and -k options sound like a reasonable
Barry> compromise to me. I'd prefer -k4 and -k5, but of course
Barry> that won't work with getopt (well, you could make it work
Barry> but it would be ugly). Of course, who says we have to keep
Barry> using getopt?
Barry> One question: What is the default authentication mode(s)
Barry> that is accepted if no options are supplied? I recommend
Barry> either none (the program just exits after sysloging a
Barry> warning and also displaying it to the krlogin client) or
Barry> insisting on krb5 with encryption (the most secure
Barry> alternative).
I believe the default should be none.
Barry> (People who use the ability of krlogind and krshd to
Barry> examine their name to find flags are more likely to wish to
Barry> name programs klogind than 54logind.)
Barry> I *STRONGLY* suggest ditching this "feature" of
Barry> krlogind/krshd as well. Most people don't even know it
Barry> exists, and it causes all sorts of problems (in fact, I bet
Barry> a large fraction of readers do not even know what you and I
Barry> are talking about in this paragraph and response). For
Barry> example, what does invoking the program as
Barry> krlogind -5
Barry> mean? Under your propose, it would accept krb4
Barry> authentication, but that is highly not obvious by
Barry> appearance. You could argue that if there are any
Barry> command-line options that the name-based options are
Barry> disabled, but again that is very confusing: what happens
Barry> when someone wants to use name-based options for
Barry> authentication but also specifies some
Barry> authentication-unrelated option on the command line?
Barry> Chaos, that's what. Name-based options were a bad idea,
Barry> they are totally non-standard, and they do not buy
Barry> anything. Get rid of them.
Unfortunately, some operating systems (Remember /etc/servers
on SunOS 3?) do not allow you to specify command line arguments. The
way our code currently works is to ignore the name of the program if
any arguments are specified. I.E. in your example, it would be a
non-encrypted krb5 logind. (I'm considering dropping the handling of
the program name even with this portability problem, but haven't
really come to a firm decision yet.)
Barry> While I'm on the topic of improving krlogin et al, I also
Barry> strongly feel that the krlogin, krsh, and krcp clients
Barry> SHOULD NOT fall back to UCB versions if the Kerberos
Barry> versions fail. The reasons are simple:
Barry> (1) It is a security hole.
So is using non-encrypted clients. (There is no fallback if
encryption is enabled.)
Barry> (2) If a site really wants to have the fallback, it can be
Barry> implemented with a shell script and be more portable and
Barry> reliable to boot. If removing this functionality from the
Barry> krb5 dist really disturbs you, you can even write the shell
Barry> script yourself and provided it. But it should not be done
Barry> in the C programs.
This sounds reasonable, and it also sounds like a good option
for the Athena environment, where we probably want a fallback to krb4
before ucb. (I'm not sure I'll have time to implement it in this
pass, but long term, removing the fallback sounds reasonable.)
Barry> IMHO, of course. :-)
Barry> Barry
--Sam
P.S. Thanks for your input.
