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