Question related to keytab entries upgrade

[Nico Williams]

On Wed, Jan 16, 2013 at 4:30 PM, Matthieu Hautreux
<matthieu.hautreux at gmail.com> wrote:
> Thanks for the explanation. I think that Nico said that having the KDC
> generating the keys enables to ensure that the keys conform to the security
> constraints of the KDC, which explains the reason why setkey privilege must
> be added to principal willing to do that. So process 1 and 2 are similar but
> only process 2 does not require to have that privilege I guess.

Did I say that?  But you know, this is really a bit of cargo cult.
Kerberos depends on having good RNGs (and good local security) on all
nodes, so clients should be able to generate long-term keys.

We could always have an RPC by which the KDC gives the client some
entropy, but really, it's not worth it.  Just use setkey and abandon
randkey.

> This discussion is interesting and after some additional thoughts I am now
> thinking of writing patches to provide the ability to automate the setkey
> process to do what I need. Here is what I would like to do, let me know if
> you think or do not think it is a valid proposal :
>
> - (1) create a new call in ktutil to add entries with a localy generated
> random key (a new -randkey option to addent)
> - (2) create a new call in ktutil based on (1) to automatically generate new
> entries of incremented kvno for a particular principal and each enctype
> found (based on (1) logic)

Note that (1) and (2) can be implemented as a script that talks to
ktutil.  And since ktutil doesn't insist on stdin/stdout being a tty
you don't even need expect(1).

> - (3) create a new call in kadmin based on setkey to automatically sync
> (push) particular kvno entries of a principal from a keytab to the kdc
> (something like "kadmin -q 'ktsync -k mykeytab myprinc at myrealm [kvno]'")

That will work.  Or if you use Roland's krb5_admin tools you just
don't have to write any code :)

Nico
--