randkey versus a big random password

[Chris Hecker]

>
> but you should be able to get the new keys back from a randkey operation


I looked at that but then it seemed like yet another roundtrip since the
initial create_principal creates a randkey on a null password and then the
randkey function makes another one?  If that's still better than a random
password performance-wise and with the other caveats you mention, that's
cool and it seems to work in my test so I can use that.

Chris


On Mon, Nov 27, 2017 at 12:54 PM, Greg Hudson <ghudson at mit.edu> wrote:

> 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 )
>