randkey versus a big random password

Greg Hudson ghudson at mit.edu
Mon Nov 27 15:54:20 EST 2017

On 11/27/2017 03:24 PM, Chris Hecker wrote:
> The version of kadm5 I'm using doesn't have the kadm5_get_principal_keys
> function, nor does it seem to ever return keys to the kadm5 client (which
> seems to have been the thing before
> https://krbdev.mit.edu/rt/Ticket/Display.html?id=8364).

The getprinc operation doesn't return client keys, but you should be
able to get the new keys back from a randkey operation.  In the command
line kadmin client, this is what the "ktadd" command does.

> I plan to upgrade
> at some point soon, but is there any advantage to trying to get a rankey
> generated key from the KDC back to my client app over just making a big
> random password and sending it over, and then using it to generate the key
> locally?  Seems like fewer round trips anyway? Is there any optimal length
> for the password (the enctype will be AES256)?

It's not fewer round trips, it's slower, there's a potential for salt
mismatch, there's a potential for kadmin to reject the password due to
the password policy, and there's a potential for the password to have
less entropy than the key.  But it's not an unreasonable option.

(To be fair, the usual approach does have a small race window where the
KDC has the new key before it is written to the server's keytab --
http://krbdev.mit.edu/rt/Ticket/Display.html?id=5339 )

More information about the krbdev mailing list