[1776] in Kerberos_V5_Development
Re: protocol flaw (160 lines) (was: krbdev vs krbcore)
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Sat Sep 21 21:13:13 1996
To: "Barry Jaspan" <bjaspan@MIT.EDU>
Cc: don@cam.ov.com, krbcore@MIT.EDU
In-Reply-To: Your message of "Sat, 21 Sep 1996 16:49:15 EDT."
<199609212049.QAA15351@beeblebrox.MIT.EDU>
Date: Sat, 21 Sep 1996 21:12:59 -0400
From: "Donald T. Davis" <don@cam.ov.com>
barry wrote:
> the KDC could just automatically hash the principal names in all
> normal requests before looking them up, thus only keeping the db
> indexed by hashed values.
> So... this idea seems to be very easy to implement, compatible with
> the existing protocol, and it provides a bona-fide security
> improvement. Sounds like a winner to me...
i agree; this is cleaner than either of the fixes i suggested
however, i don't see why it has to be handled as preauth. why
not just change the user-id part of the request's name field
to be a hash instead of ascii? all i can think of is that this
might interfere with inter-realm name-handling. i can see that
this is sort of a protocol change, but it's a minor one, and
it seems a lot cleaner than using the dummy+preauth hack.
one potential problem is hash-fcn collisions, however improbable.
however, a 16- or 20-byte hash value will be unlikely to collide,
and even if it does, the admin will discover the collision when
he tries to create the account. it will be hard to explain to
rachel that she can't have the uid "rachel@mit.edu" because it's
identical in hash to "drgonzo@mit.edu."
i'm not wild about marc's hesiod-based fix, just because i'd rather
not couple krb tightly to hesiod. i have nothing against hesiod,
but not every krb site will necessarily want to have to adopt it.
am i correct in believing that krb doesn't currently depend on
hesiod's availability?
-don
