Question related to keytab entries upgrade

[Russ Allbery]

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