[OpenAFS] 'afs/' principal rekeying instructions may be incomplete

[Peter Grandi]

[ ... ]

>> The issue here is that at least in MIT kerberos 1.8 and 1.10
>> which I tested this on this results in the loss of the existing
>> single-DES key from the KDB, which probably results in existing

> The loss of the existing single-DES key is expected and desired.

>> single-DES tokens and client to stop working as the key in the
>> 'KeyFile' is no longer matched by one in the KDB:

> It does not cause the existing single-DES tokens to stop
> working. The existing tokens are derived from kerberos tickets
> issued against the old key, but once the service ticket is
> issued, the KDC is out of the picture.

The service tickets are renewable. See below.

> So long as the key remains in the KeyFile on the AFS servers,
> the ticket (and thus token) can be verified.

>> To avoid this one has to use 'kadmin.local' to be able to use
>> 'cpw -keepold' and 'ktadd -norandkey', as advised in the MIT
>> kerberos "Retiring DES" HOWTO:

> This is the correct way to avoid the loss of the old keys from
> the KDB, but it should not be necessary to retain the old keys
> in the KDB for the purposes of an rxkad-k5 migration.

The point made by somebody else here is different, and that
using 'kadmin.local' with 'cpw -keepold' and 'ktadd -norandkey'
is more risky than using 'kadmin' with 'ktadd'; I think that the
argument is: in part because the latter is a simpler procedure,
in part because using 'kadmin.local' is perceived as more risky
than 'kadmin', in part because the official procedure contains
only the latter.

Is there any _technical_ risk in using the "avoid the loss of
the old keys" procedure?

> [ ... ] Can you clarify a bit more why you believe it is
> necessary to preserve these keys in the KDB?

Well, "first do no harm". Both Kerberos and OpenAFS seem to me
to have a large number of (to be charitable) corner cases, and
my instinct is to cautious.

Thus my aim was to keep both the single-DES key and 'Keyfile'
for a while (I am well aware that as long as they exist there is
no extra authentication security from the other keys and keytab)
check the KDC logs to see whether any new single-DES tickets for
'afs/cell' are generated in the next week (we have the usual 1
week max renewal) and then when I am really sure all renewable
single-DES tickets have expired and no new ones have been issued
I will delete the single-DES key and 'KeyFile'.

Apart from running fairly critical services on top of OpenAFS,
and having already disrupted them a bit because of 1.4 to 1.6
upgrading and DB server reorganization as in the 'vos' lockup),
I find reason to be cautious for example in this advice in the
1.6 HOWTO:

  "On OpenAFS 1.6.5, this is best achieved by renaming the
  KeyFile out of the way, but retaining it so that it can be
  reinstated if one of the previous steps was incomplete."

Keeping around the 'KeyFile' so it can be restored does not make
sense unless the matching key is preserved too. Unless the above
strictly refers to keeping it aorund for the sake of already
existing tokens.

Also, our OpenAFS cell has been running largely unchanged for
many years, and I don't know in detail how some of the client
services using it are configured.

For example I know that several run under 'k5start', and I don't
know which enctypes are in those keytabs. I am fairly sure they
include non-DES enctypes, but then I would have to check each of
them.

But then I am not sure what 'k5start' when it renews a ticket.
If it keeps using the same single-DES key then renewal will fail.

With further investigation I may well be able to find out, and
I have already listed all principals that have requested AFS
tickets in the past several months, but I'd rather have peace of
mind without double checking a lot of details.

> The presence of the single-DES keys in rxkad.keytab is
> actually a problem. The rxkad-k5 code was written so as to be
> as "minimally disruptive" as possible, meaning that for
> single-DES keys the old code paths will still be used.

Yes, that's exactly what I was counting on in my cautious plan
to keep the single-DES around for a while.

> In particular, that means that when receiving a token that's
> encrypted in a single-DES key, the AFS server will look in the
> KeyFile for that decryption key. If the key is only in
> rxkad.keytab, it will fail. [ ... ]

So if I keep the 'KeyFile' until all possible single-DES tickets
have fully expired this is not an issue :-).