kdb5_util -b7 dump format

[Greg Hudson]

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.