kadm5_rename_principal salt question

[John Hascall]

> John Hascall <john at iastate.edu> writes:
> > And why would it not be possible to do something like the following?
> >     if ((kdb.key_data[i].key_data_ver == 1) ||
> >         ((kdb.key_data[i].key_data_type[1] == KRB5_KDB_SALTTYPE_NORMAL) &&
> >          (kdb.key_data[i].key_data_length[1] == 0))) {
> >         krb5_principal2(handle->context, entry->principal, &salt_data);
> >         kdb.key_data[i].key_data_ver = 2;
> >         kdb.key_data[i].key_data_type[1] = KRB5_KDB_SALTTYPE_NORMAL;
> >         kdb.key_data[i].key_data_length[1] = salt_data.length;
> >         kdb.key_data[i].key_data_contents[1] = (krb5_octet *)salt_data.data;
> >     }

> > thus putting in an explicit salt of the soon-to-be-old-name of the
> > principal.  This could then be updated (or removed) at the principal's
> > next password change.

> How would a client know the salt in order to derive the same key to
> decrypt a KDC reply?

I was under the impression that some of the new encryption types
(like AES) you had to specify the salt -- I'm trying to understand
why you would be keeping an explicit salt in the DB otherwise -- so
I was assuming the salt came back with the ticket.

John