Question related to keytab entries upgrade

[Matthieu Hautreux]

Greg, Russ, thank you for your prompt and detailed replies.

an active kvno flag or an effective date for principals would certainly be
interesting in the KDC to remove the race window. Both need modification in
the DB backend and are thus certainly quite complicated to implement. Do
you know if the DB schema is something that is often modified or is it
still the same since the early beginning of the project ?

I was not aware that service principals were implicitely allowed to refresh
their keytab entries and that solution, coupled with the removal of the
keytab management from the configuration management tool and the opening of
the port on the firewall, is probably the best solution for now if I need
to do hot-add keytab entries.

I will try to take a look at the setkey RPC to see how it could be used for
that too. Indeed, one of the targeted use case is the management of a large
number of nodes on clusters where nodes can be regularly deployed and
synced to their expected configuration (conf files+keytab) using puppet
after the deployement. Having to deal with kerberos details during that
process was not the selected option as the person in charge of that are not
familiar with kerberos or are not allowed to access the KDC. If the process
can be automated on the cluster management node, allowed to do the setkey
RPC in the ACL, it could help to let cluster administrators managed the
system as usual while ensuring the synchronicity of principal entries in
keytab and KDC DB. If I eventually go into that direction, I will let you
know and most probably ask for your views on design and key generation
methods on the client side.

In the meantime, if a decision is made to add the active kvno or effective
date to the dev/main branch, I am ready to help in testing or even doing
some code (or code review) for the feature.

Thanks again.

Regards,
Matthieu


2013/1/14 Russ Allbery <rra at stanford.edu>

> Matthieu Hautreux <matthieu.hautreux at gmail.com> writes:
>
> > - a client still owning an older version of a TGS will still be able to
> > contact the associated service as long as the services will have access
> > to both the older and the new version of the entries (different kvno)
>
> Correct.
>
> > - new clients will get the new version of the TGS key and will only
> > contact successfully a service that will be in possession of the new
> > keytab entry.
>
> Correct.
>
> > To do that upgrade of keytab principal entries, I can either (1) do the
> > upgrade of principal keys on the KDC and push the additional entries to
> > the different machines for addition in current keytabs or (2) do that
> > directly on the machine using kadmin if kadmind is using a coherent ACL
> > and a port that is not filtered from the different machines.
>
> Those two options are not actually different internally, only in timing,
> if you use -randkey.  The kadmin call (with -randkey) does, in sequence:
>
> 1. Create a new key.
> 2. Add the new key to the principal entry in the KDC database.
> 3. Return the new key to the client as a keytab.
> 4. Write the new key out to the client keytab.
>
> There is therefore a race condition between 2 and 4 if any clients obtain
> a service ticket for the service and then attempt to authenticate to the
> service within that window.  It's not a very long window, and you can
> usually ignore it for practical purposes, but it does exist.  Your (1)
> option just makes the window much longer.
>
> > If I use (1), I need to be sure that no clients will request for a TGS
> > for updated principals as long as the new entries are not added on the
> > server machines, thus this method is only limited to maintenance period
> > where I can guarantee that no one will try to access the servers in the
> > update process.
>
> Correct.
>
> > If I use (2), I do not have to take that synchronization effect into
> > account, but I need to open the firewall and ACL. Moreover, I am used to
> > use configuration management tools like puppet or cfengine to manage
> > configuration files (including keytabs) on a central management node,
> > this method (2) does not really cope wit this requirement as every
> > server will update locally its keytab and the configuration management
> > node will ask him to go back to the previous version every time.
>
> If you are deploying keytabs with your configuration management system,
> correct.  (Generally I would not recommend doing that, since usually
> keytabs are more secure than the configuration management system is, but
> it will depend a lot on the specifics of your local situation.)
>
> > I am wondering if I am missing an other approach that would let me
> > create new versions of principal keys on the KDC, generate the
> > associated keytab entries (increased kvno), push+add them to the
> > targeted servers keytabs (when I want) and then inform the KDC to use
> > the new version in consecutive TGS_REQ calls. With such a workflow, I
> > could guarantee that everything is always working as expected and do a
> > hot-"rolling upgrade" of all the keytabs with a centralized management
> > system and without having to add every node to the ACL and alter the
> > firewall rules. I have taken a quick look at the KDC code, and it seems
> > that the KDC is always looking for keys of highest kvno number when
> > performing a TGS_REQ, so it must not be possible, but in case I am wrong
> > and someone is knowing how to do that, or an other alternative for my
> > problem please let me know.
>
> The best solution to this problem is to add an effective date to keys in
> the KDC database so that the KDC will not use those keys for service
> tickets until the effective date is reached, but will make them available
> via other means (such as ktadd).  This is a long-standing request and is
> necessary for doing fully correct key rollover, but it requires changing
> the database format and some of the protocols.  I don't believe this has
> been done yet in any version of MIT Kerberos.
>
> You can approximate this by giving up on -randkey and instead generating
> your own random password that you'll use to generate the service keys.
> This is less than ideal since you're now at the mercy of your password
> generator and the string to key function to get a fully random key, and
> you will probably lose some key space.  However, that way you can use
> ktutil to add the key (via password) to each system with a higher kvno,
> and then, once that process is complete, use the same password to add the
> key to the KDC, which ensures there are no race conditions.  There aren't,
> however, any standard tools for doing this process.
>
> --
> Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>
>