[33630] in Kerberos
Re: keytab, kvno, ktadd, and existing tickets
daemon@ATHENA.MIT.EDU (Chris Hecker)
Sat Jul 23 04:02:31 2011
Message-ID: <4E2A800E.6060702@d6.com>
Date: Sat, 23 Jul 2011 01:02:22 -0700
From: Chris Hecker <checker@d6.com>
MIME-Version: 1.0
To: "kerberos@mit.edu" <kerberos@mit.edu>
In-Reply-To: <87bowlsarp.fsf@windlord.stanford.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
> If downloading a key always changes it, then the attacker has to make
> a visible attack that breaks the existing key and therefore existing
> services.
That makes sense.
Maybe I add ktexport only when building as kadmin.local as a compromise.
It would allow people to use it for debugging problems (like my use
case), and if they wanted to actually generate a new one "in
production", at least then they'd have to also have root on the KDC,
which, if they had root, they'd be able to just rip it out of the db
anyway with the kadm5 lib like Nico was saying.
If I was in there modifying kadmin.local, I'd also fix the message that
says it's "Authenticating as principal root/admin@BLAH.COM with
password." which is not actually true, nor does that princ even exist in
my kdc. :) It looks like it already checks for kadmin.local in one
spot, so there's some precedent, although this would need an #ifdef
rather than a dynamic check.
Chris
On 2011/07/23 00:42, Russ Allbery wrote:
> Chris Hecker<checker@d6.com> writes:
>
>> And yeah, a ktexport command would be nice in kadmin. Maybe I'll look
>> at doing that if I have to do this more often. This was only during
>> testing, so hopefully it won't be too common of an occurance.
>
> The code is all there already and would be fairly easy to enable over the
> network protocol. It's not there more as a matter of policy than because
> of a lack of implementation.
>
> Ideally, you don't really want to allow redownloading a key because you
> enable a silent attack on that key if the attacker somehow gains access to
> the kadmin protocol. If downloading a key always changes it, then the
> attacker has to make a visible attack that breaks the existing key and
> therefore existing services. Ideally, you only have one keytab for any
> given principal because all of your keys are host-based and you never use
> the same key in more than one place.
>
> In practice, the world isn't that nice, so it ends up being a usability
> versus security tradeoff. Many large organizations that I've talked to
> have ended up having some need to share the same keytab on multiple
> systems for one reason or another.
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
