kr-cmds and dropping login.krb5 (was RE: Is anyone or a group of people able to maintain appl/bsd betterthan MIT)

[Nicolas.Williams@ubsw.com]

On Wednesday, July 24, Russ Allbery wrote:
> I agree with Booker here in that I think it definitely requires work,
> although I'm perhaps a bit more optimistic about how much work it
> requires.  I simply don't see much alternative.  We need them 
> and we'll
> have to maintain them one way or another.  I don't expect to 
> see the world
> in which we can replace them all with ssh any time soon, particularly
> given the security problems that are plaguing ssh implementations.

I see no reason not to use OpenSSH w/ Simon's patches. Bugs are bugs;
they happen. And it so happens that OpenSSH is easier to maintain than
the MIT BSD-derived kerberized r-commands and login.krb5; well, to me
it is. It's all in the eye of the beholder, I suppose, but I see far
more development/support activity around OpenSSH than I do around the
MIT krb5 appl/bsd/* stuff, and I see OpenSSH as being much cleaner,
and I have no major complaints about the OpenSSH track record with
respect to security bug fixes - as for the track record with respect
to bug occurrence, that's already been dealt with here.

And this is as it should be. I would like the MIT folk to be able to
concentrate on improving the libraries and the KDC/kadmin stuff - the
core of MIT krb5.

[...]

> I know it would really be nice from our perspective to figure 
> out vaguely
> clean ways to do the things that we need to do (like support for users
> without .klogin / .k5login files under certain circumstances, 
> stuff like
> that that isn't particularly clean but is important to a 
> large percentage
> of our user base) that could go into central CVS somewhere so that we
> don't have to keep maintaining them as local patches and doing nasty
> merges with every new release of Kerberos.  Even if we still have to
> maintain all of that code, just not having to do merges would 
> save a chunk
> of time.

Well, let's see, OpenSSH w/ Simon's GSS patches and MIT or Heimdal
krb5 supports the use of GSS/Kerberos for network authentication,
and the sshd doesn't actually need or use login.krb5, not at all.

It does depend on krb5_kuserok(), and therefore on ~/.k5login /
krb5_aname_to_lname() (which you state you don't want). UNLESS you
have my patches, or write some like them, which allow authorization
based on Kerberos principal names via authorized_keys entries -
since you can tell sshd where the auth_keys files live you need
not depend on ~/.k5login.

So why, oh why must we keep login.krb5, with or without local hacks?

I would not mind sticking with MIT krb5's telnetd if it could be
easily configured to use /bin/login, but that's not the case - and
I do need a kerberized telnet daemon for Unix that uses /bin/login.

IMO, krlogin/klogind/krsh/krshd should be easy to implement and
maintain if:

 - login.krb5 is dropped (krsh/krshd doesn't use login.krb5)
 - krb4 support is dropped

Dropping login.krb5 requires that /bin/login support the -f option,
which is indeed generally supported by OSs that support rlogind /
ruserok().

Consider that dropping login.krb5 means dropping all that ugly
OS-specific code, such as the utmp code.

Cheers,

Nico
-- 

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.