[19696] in Kerberos_V5_Development
Re: randkey versus a big random password
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Nov 27 15:54:41 2017
To: Chris Hecker <checker@d6.com>, krbdev@mit.edu
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <4330ace3-ea7e-65a6-1a54-254bf626004c@mit.edu>
Date: Mon, 27 Nov 2017 15:54:20 -0500
MIME-Version: 1.0
In-Reply-To: <CAOdMLc36-X16O4EL=zWJa-M=GaCZthMyJrXT+pwk4LWN1FcDFg@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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 )
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
