cjones@rupert.oscs.montana.edu (Chris Jones) writes:
> The API for krb5 changed between one of the betas and the current, 1.0
> release.

While I'm far from a krb5 guru, I watch the krb mailing-list a bit.
One thing that you need to be aware of is that the current krb5
login.c (.../krb5-1.0pl1/src/appl/bsd/login.c) changed quite a bit
from the early krb5 days.  It appears that netbsd's login.c is a copy
of a very early krb5 snapshot.  

There is a nasty spoofing attack that the netbsd login.c is subject
to. An attacker spoofs a kdc and floods the target machine with his
own tgt replys.  The attacker gets to choose the password he types at
"login" and naturely choses the same password to encrypt the spoofed
tgt with.  The tgt won't be useful for anything -- its bunk, but the
old login just looked to see if it got a decodable tgt, which it will
have.  It never tried to use the tgt for anything.  The new krb5
login.c verifies the tgt by trying to use it.  Search for
"verify_krb_v5_tgt()" to see the heart of the change.  This prevent as
bunko tgt from letting someone log in.

I can't tell what changes were made to the netbsd login.c.  (Someone
with CVS access can easily diff against the earliest version.)  It may
be easier to just use krb5's login.c  Thats what I do here.  Just copy
/usr/local/sbin/login.krb5 to /usr/bin/login .  Krb's login is meant
to be a superset.  I don't know if it really is -- I suspect not.

Are there any plans to dump the crusty old krb4 and upgrade to the
current krb5?  What sort of prodding and/or diffs would be needed for 
core to accept MIT's krb5?

I'm eager to see krb upgraded since there is a ld.so name clash
between krb4's and krb5's libcom_err.so.*.* that messes up a krb5
installation.

-wolfgang
-- 
Wolfgang Rupprecht    <wolfgang@wsrcc.com>         http://www.wsrcc.com/
Fun anti-spam tactic:  http://www.hotwired.com/packet/97/23/index3a.html