[11289] in Kerberos-V5-bugs
[krbdev.mit.edu #6546] KDB should use enctype of stashed master key
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Thu Jan 7 15:55:34 2010
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6546@krbdev.mit.edu>
Message-ID: <rt-6546-32085.9.01924164270909@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6546'":;"'AdminCc of krbdev.mit.edu Ticket #6546'":;@MIT.EDU
Date: Thu, 7 Jan 2010 15:55:30 -0500 (EST)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
The problem is actually more constrained than I actually thought. If
you have a stashed master key, master key retrieval works just fine
regardless of the default master key enctype. However, there are two
big caveats:
1. When you start up kadmind or kadmin.local, the kadmin/history key is
retrieved using krb5_dbe_find_enctype with the default master key
enctype specified; this fails if the database was created with a
different master key enctype. This is easy to fix and will be fixed
shortly.
2. If you type out the key using krb5kdc -m, you get:
krb5kdc: Unable to decrypt latest master key with the provided master key
- while fetching master keys list for realm TEST.ORG
if the master key enctype is not the default (and is not specified via
the -k option). We can be friendlier than that, by looking up the key
type in the K/M entry. This is a little less trivial to fix.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
