I have a server application that wants to periodically randomize its service key. This key MUST be a des-cbc-crc key, and it MUST be the only current key for the service principal (for reasons that I don't want to discuss right now; suffice it to say that my application won't interoperate with its clients if the KDC is going around handing out service tickets with other key types for my service). (I know that single-DES isn't necessarily the tightest cipher in the implementation, but it's really not up for discussion.)
I'm trying to do this by using kadm5_init_with_skey to the changepw service, using my current key, and then kadm5_randkey_principal_3, passing a key-salt tuple containing only one entry: des-cbc-crc:normal. (And then calling kadm5_get_principal to get my new kvno, since kadm5_randkey_principal_3 doesn't give me back that useful nugget of information...) The problem is that kadm5_randkey_principal_3 returns TWO keys: a des3-cbc-raw key and a des-cbc-crc key. Since it contains a des-cbc-crc key in the list, I can paw through it and get that key, but this result doesn't meet my second requirement: that the des-cbc-crc key be the ONLY current key for the service principal. (I'm seeing this behavior running MIT k5 1.2.4, and observed the following in the 1.2.5 source tree.) I've traced through the code, and it appears that if the calling principal matches the principal whose key is being changed, the server-side wrapper calls randkey_principal_wrapper, which ignores the ks_tuple argument and calls kadm5_randkey_principal instead of kadm5_randkey_principal_3. (And, maddeningly enough, kadm5_randkey_principal calls kadm5_randkey_principal_3 with a fixed set of ks_tuples.) Bummer. Is there a good reason for this? Is it fixed in 1.2.6? (Seems to me that one Q&D fix would be trivial: have a randkey_principal_3_wrapper that calls kadm5_randkey_principal_3 at the end instead of kadm5_randkey_principal. But I can't go around handing out kadmind patches to sites that want to use my server.) Is there a workaround that doesn't require my keeping credentials around for some other principal that has the changepw privilege? (If the calling principal is someone else, calling the kadmin service, with the changepw privilege, it works fine, but I don't want to store a key for that principal. Thanks in advance for any suggestions, -- Ben ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] http://mailman.mit.edu/mailman/listinfo/kerberos
