> 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/[email protected] 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<[email protected]> 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 [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
