I'm wondering if someone can help me better understand the kdb5_util dump format.
I'm using the -b7 format flag.
Does this have the historical keys in it (i.e. from password history setting)?
If so, are they encrypted with the history key (and then the master key on top of that)?
How can I tell by looking, which ones are the current keys vs the historical keys? I think the kvno is in there somewhere?
I just want to make sure I am reading this right.
On 12/10/2018 01:23 PM, Jerry Shipman wrote:
> I'm wondering if someone can help me better understand the kdb5_util dump format.
> I'm using the -b7 format flag.
> Does this have the historical keys in it (i.e. from password history setting)?
Historical keys are contained within a tl-data value ("tl" stands for
"tag-length"). The principal format is (tab-separated fields):
"princ" len strlen(name) n_tl_data n_key_data e_length
So the tl-data values begin at the 16th field, with three fields per
value. The one with type 3 (KRB5_TL_KADM_DATA) is the kadm5 tl-data
item. The corresponding contents field is the hex encoding of the the
XDR encoding of an osa_princ_ent_rec structure (see
So that's pretty inconvenient to get at, especially without
documentation on the dump format (I have a to-do item to write that page
now that we have a docs section on formats). In release 1.14 we added a
"kdb5_util tabdump" subcommand which knows how to decode the kadm5
tl-data and can output a little bit of that information (the policy
reference and the history kvno), but not the historical keys.
> If so, are they encrypted with the history key (and then the master key on top of that)?
Historical keys are encrypted with the history key, but not the master key.
> How can I tell by looking, which ones are the current keys vs the historical keys? I think the kvno is in there somewhere?
None of the key data fields in the dump record are historical keys in
the sense of having been created by or consulted by the password history
feature. Key data entries with old kvno values are the result of kadmin
cpw -keepold or kadmin randkey -keepold.
If this all seems haphazard, it's because the kadm5 framework was
originally written as an addon by a separate development team, and later
incorporated into the main krb5 tree without changing how its database
fields were represented.
Kerberos mailing list [hidden email] https://mailman.mit.edu/mailman/listinfo/kerberos