kadm5_rename_principal salt question

[Marcus Watts]

> (Message inbox:38984)
> 
> Date:    Mon, 24 Sep 2007 10:43:57 PDT
> To:      krbdev at mit.edu
> From:    Russ Allbery <rra at stanford.edu>
> Subject: Re: kadm5_rename_principal salt question
> 
> 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?
> 
> -- 
> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

My recollection from having chased this down a *long* time ago
is that "KRB5_KDB_SALTTYPE_NORMAL" isn't sufficient; you have
to make it "KRB5_KDB_SALTTYPE_SPECIAL".  As long as you don't
have more than one salt (per enc type) that maps into
KRB5_KDB_SALTTYPE_SPECIAL this works fine.  It does require that
the client understand preauth sufficiently to pick up the salt.

Here's what we use at umich:
/afs/umich.edu/group/itd/build/mdw/tmp/k5/rename_princ.patch

I'm hoping to rework this patch to make it more acceptable in
some future kerberos distribution.  Since this is inherently somewhat
site specific, I plan to put a plugin architecture here and
have a plugin which implements the actual site specific policy.
Ideally, it would be nice if this could be completely specified
in the configuration file - but the general case of that strikes
me as likely to be way too complicated.

					-Marcus Watts