[6520] in Kerberos
Re: Request for input: proposed krshd and krlogind option reorganization
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Tue Jan 23 15:47:55 1996
Date: Tue, 23 Jan 96 11:59:03 EST
From: "Barry Jaspan" <bjaspan@bbnplanet.com>
To: hartmans@MIT.EDU (Sam Hartman)
Cc: kerberos@MIT.EDU
In-Reply-To: [6519]
Sam,
Thanks for tackling this messy collection of issues.
First, there is serious discussion of dropping support for
.rhosts files in krlogind and krshd... [proposal to] remove support for
requiring that a user present both valid Kerberos authentication and
rhosts authentication in the same session (-K -R under the current
options).
I suggest removing all support .rhosts entirely, including the -r
option you propose below. There is no reason to provide .rhosts
functionality in a Kerberos rlogind. If a site wishes to support
Kerberos authentication and rhosts authentication (which is pretty
silly), it can simply run their vendor's rlogind on the standard port
and krlogind on the klogin port.
So, we propose the following options to select encryption and
authentication for krlogind and krshd:
- -e: enable encryption on krlogind, require it on krshd
Why the difference between krlogind and krshd? That will be
confusing. If you want one to allow and another to insist, use
something like -e and -E.
- -r: Accept .rhosts authentication
IMHO, punt entirely, as described above.
The -4, -5, and -k options sound like a reasonable compromise to me.
I'd prefer -k4 and -k5, but of course that won't work with getopt
(well, you could make it work but it would be ugly). Of course, who
says we have to keep using getopt?
One question: What is the default authentication mode(s) that is
accepted if no options are supplied? I recommend either none (the
program just exits after sysloging a warning and also displaying it to
the krlogin client) or insisting on krb5 with encryption (the most
secure alternative).
(People who use the ability of krlogind and krshd to examine their
name to find flags are more likely to wish to name programs klogind
than 54logind.)
I *STRONGLY* suggest ditching this "feature" of krlogind/krshd as
well. Most people don't even know it exists, and it causes all sorts
of problems (in fact, I bet a large fraction of readers do not even
know what you and I are talking about in this paragraph and response).
For example, what does invoking the program as
krlogind -5
mean? Under your propose, it would accept krb4 authentication, but
that is highly not obvious by appearance. You could argue that if
there are any command-line options that the name-based options are
disabled, but again that is very confusing: what happens when someone
wants to use name-based options for authentication but also specifies
some authentication-unrelated option on the command line? Chaos,
that's what. Name-based options were a bad idea, they are totally
non-standard, and they do not buy anything. Get rid of them.
While I'm on the topic of improving krlogin et al, I also strongly
feel that the krlogin, krsh, and krcp clients SHOULD NOT fall back to
UCB versions if the Kerberos versions fail. The reasons are simple:
(1) It is a security hole.
(2) If a site really wants to have the fallback, it can be implemented
with a shell script and be more portable and reliable to boot. If
removing this functionality from the krb5 dist really disturbs you,
you can even write the shell script yourself and provided it. But it
should not be done in the C programs.
IMHO, of course. :-)
Barry
