Question related to keytab entries upgrade

[Matthieu Hautreux]

Nico, Greg, sorry for the confusion in your identities ! I should have read
again the whole thread before replying.

I tried to take into account Greg explanation (first reply to this thread)
when defining the (1) (2) (3) logic.
Thus having a 'ktutil addent -randkey ...' using krb5_c_make_random_key
sounded to me like a possibility to use kerberos internal RNG on the client
and enforce the equivalent policy that the KDC is using when creating the
new entries. am I correct ?

krb5_admin seems to have a lot of nice feature doing that and a lot more.
If I can just put the logic I described in a local version of MIT packages
that will be sufficient for me. I already had to compile local krb5
pacakages because of unexpected issues with the recently introduced poll
logic (infinite poll loop, I had to disable it) and to add patches for ACLs
on the KDC  filtering incoming AS_REQ/TGS_REQ (proposed on this mailing
list in december 2011). I can add that too :).

IMHO the main branch of krb5 would benefit from such a feature to provide
natively an alternate support of hot-add of keytab entries, thus limiting
the race window for indirect hot-add.

If I succeed in doing what I want, I will propose it and see if it seems
interesting enough to be integrated in a future release.

Regards,
Matthieu

2013/1/17 Nico Williams <nico at cryptonector.com>

> On Wed, Jan 16, 2013 at 5:46 PM, Nico Williams <nico at cryptonector.com>
> wrote:
> > On Wed, Jan 16, 2013 at 5:37 PM, Greg Hudson <ghudson at mit.edu> wrote:
> >> I said it.  I wasn't talking about RNG quality.  With the setkey RPC,
> >> the KDC doesn't know whether the client chose the key randomly at all;
> >> it could be the string2key output of a password which wouldn't pass the
> >> password policy.
> >
> > Ah, yes, there's that.
>
> Of course, one can always just deny setkey to principals with password
> quality policies.
>