Question related to keytab entries upgrade

[Matthieu Hautreux]

Dear all,

after some work and evaluation, you will find enclosed a set of patches
against the main branch of MIT krb5 to add the support for client side
principals hot-rekeying removing the race window discussed in this thread.

I have also included a document explaining the logic and the reasons of
this addition.

To sum up the document, the patches add 2 new sub-commands, one in ktutil
(ukt), the other in kadmin[.local] (ktsync).

ktutil/ukt helps to upgrade the entries of a keytab while kadmin/ktsync
helps to synchronize the KDC entries associated with a principal using an
upgraded keytab. This 2 new commands enable to asynchroneously rekey
kerberos principals without introducing a potential race window where
clients could be denied access to a kerberized service while this one is
rekeying (example of usage in the enclosed notes).

Let me know if you find that feature interesting enough for an inclusion in
the main branch and/or if you want me to refine the logic or correct some
code or coding style.

I have backported patches for CentOS-6.{0,3} too (krb5-1.8 and 1.9). If
someone is interested in that, let me know.

Best regards,
Matthieu

2013/1/17 Matthieu Hautreux <matthieu.hautreux at gmail.com>

> 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.
>>
>
>