randkey versus a big random password
checker at d6.com
Mon Nov 27 16:26:47 EST 2017
> 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.
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
> > locally? Seems like fewer round trips anyway? Is there any optimal
> > 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