randkey versus a big random password

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

randkey versus a big random password

Chris Hecker
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). 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)?

Thanks,
Chris
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: randkey versus a big random password

Greg Hudson
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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev