On 12/10/2018 01:23 PM, Jerry Shipman wrote:
> Hello,
> 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
name
attributes max_life max_renewable_life expiration
pw_expiration last_success last_failed fail_auth_count
n_tl_data*[type length <contents>]
n_key_data*[ver kvno ver*(type length <contents>)]
<e_data>
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
src/lib/kadm5/server_internal.h).
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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
