[1433] in Kerberos_V5_Development
Why can you not rename a random key with the new admin server?
daemon@ATHENA.MIT.EDU (epeisach@MIT.EDU)
Sat Jul 27 11:45:42 1996
From: epeisach@MIT.EDU
Date: Sat, 27 Jul 1996 11:45:27 -0400
To: krbcore@MIT.EDU
Am I confused, but shouldn't you be able to rename a random key?
According to the specs, the warning is regarding using the principal
name as a salt for the principal's key - hence the string-to-key may
fail.
key_data_ver is 1 if the key is a random key (not requiring a salt) or
the normal v5 salt.
Looking at the kadm5 code, you can rename what I consider unsafe
principals, but you cannot rename a random key...
The following salltypes are safe to rename: (based on my reading the code)
SALTTYPE_ONLYREALM
KRB5_KDB_SALTTYPE_V4
unsafe:
SALTTYPE_NOREALM
SALTTYPE_NORMAL
(I am not sure about the AFS3 type)
Random keys are created with SALTTYPE_NORMAL and key_data_ver=1 (no
salt needed to be stored). From looking at the code, I believe there is
a failure in terms of the logic:
I read it as if no saltype is stored in the database
(i.e. random key or normal v5 salt) or you are using the normal
SALTTYPE_NORMAL then you cannot rename the key. You can rename the key
however if SALTTYPE_NOREALM is used - which strikes me as
unsafe. (i.e. the code probably needs to be changed)
So I guess the real problem is that there is no way to distingush
between a random key and the "salttype_normal" variety? Or perhaps,
maybe random keys should set the salttype to SALTTYPE_ONLYREALM?
Or am I completely confused by the matter and one cannot rename a random
key...
ezra
Background:
The relevant code is: (lib/kadm5/srv/svr_principal.c)
if ((kdb.key_data[i].key_data_ver == 1) ||
(kdb.key_data[i].key_data_type[1] == KRB5_KDB_SALTTYPE_NORMAL)) {
ret = KADM5_NO_RENAME_SALT;
Now, according to the api-funcspec.tex (/mit/krbdev/doc/specs/admin/lib)
\item[key_data_ver] The verion number of the structure. Versions 1
and 2 are currently defined. If key_data_ver is 1 then the key is
either a random key (not requiring a salt) or the salt is the normal
v5 salt which is the same as the realm and therefore doesn't need to
be saved in the database.
Under kadm_rename_principal:
Note that since the principal name may have been used as the salt for
the principal's key, renaming the principal may render the principal's
current password useless; with the new salt, the key generated by
string-to-key on the password will suddenly be different. Therefore,
an application that renames a principal must also require the user to
specify a new password for the principal (and administrators should
notify the affected party).
