Question related to keytab entries upgrade

[Matthieu Hautreux]

2013/1/24 Greg Hudson <ghudson at mit.edu>

> On 01/23/2013 05:20 PM, Matthieu Hautreux wrote:
> > 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.
>
> At the moment, I am more partial to a design using a server kvno
> attribute in the DB entry.  It's significantly more work, but (1)
> because keys would still be generated within kadmind, it finesses the
> issue of setkey permissions; and (2) it would allow kinit -k to continue
> to work without requiring the client code to retry with multiple key
> entries.
>
> Having an active kvno flag in the KDC would definitely be a good solution.
However, it is far from being feasible to me as I do not have enough
knowledge of the db backend(s) logic and I am not sure of the result in
term of compatibility with older versions of kerberos if I touch that part
of the code. So I think that I will wait for the main branch to work on
that, do you think that it is something that could be done on a mid-term
basis ? For the enxt major version perhaps ?

As I am currently using kerberos with RHEL/CentOS 6.x distributions, I
would have to backport such modifications to krb5-1.9 which could be quite
difficult. I think that I will maintain the proposed patches for at least
the 6.x distributions and see with RHEL7 if something has append for that
issue in the meantime and is available for direct use in the krb5 flavour
used at that time.

However, I think that having a client side approach for that issue is still
interesting as (a) it does not involve a lot of modification in the code,
(b) the set-key acl requirement lets administrators decide which principal
is able to use the feature, (c) the generated keys use the same randomness
as the KDC when rekeying the entries and (d) it provides a reason for being
to the set-key RPC :)

Concerning your points, I am okay with (1)  but the (2) will still require
to add the retry logic on the KDC as it will have to provide valid AS_REP
to AS_REQ coming from an inactive kvno or the highest active kvno. If not,
it will also have to be done on the client side in the library.

As suggested by Benjamin Kaduk, I have sent a pull request using github as
it seems that the mailman strip the attachments of my last email.

Regards,
Matthieu