[33629] in Kerberos
Re: keytab, kvno, ktadd, and existing tickets
daemon@ATHENA.MIT.EDU (Russ Allbery)
Sat Jul 23 03:42:56 2011
From: Russ Allbery <rra@stanford.edu>
To: "kerberos\@mit.edu" <kerberos@mit.edu>
In-Reply-To: <4E2A795E.5030808@d6.com> (Chris Hecker's message of "Sat, 23 Jul
2011 00:33:50 -0700")
Date: Sat, 23 Jul 2011 00:42:50 -0700
Message-ID: <87bowlsarp.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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.
--
Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
