[19697] in Kerberos_V5_Development
Re: randkey versus a big random password
daemon@ATHENA.MIT.EDU (Chris Hecker)
Mon Nov 27 16:27:00 2017
MIME-Version: 1.0
In-Reply-To: <4330ace3-ea7e-65a6-1a54-254bf626004c@mit.edu>
From: Chris Hecker <checker@d6.com>
Date: Mon, 27 Nov 2017 13:26:47 -0800
Message-ID: <CAOdMLc2=h6iXqDBKYFM8PnPj306wfCa9G8C35qdFo74AhMAB6Q@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
>
> 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@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 )
>
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
