[OpenAFS] Re: 'afs/' principal rekeying instructions may be incomplete
Thu, 23 Jan 2014 19:18:58 +0000
>> [ ... ] results in the loss of the existing single-DES key
>> from the KDB,
> That is intentional and expected.
Perhaps it should be noted in the procedure then. I have noticed
that the language in the procedure is somewhat ambiguous on
keeping or removing the single DES keys from the principal, for
"(even if the service principal contains a DES long-term key,
which is okay)."
I have appended the notes I had written based on the sometimes
ambiguous (in retrospect it is not always clear whether "key"
means the key in 'KeyFile' or in the KDB) language of the
> It does not prevent any already-issued tokens from working, but
> it does make authentication not work correctly for any new
> tokens until you distribute the new rxkad.keytab file.
[ ... ]
> That part of the document is talking about the krbtgt/ service
> principal, which is a special case. If you retain the old DES
> key while rekeying the afs/ service principal, it doesn't
> really... do anything. At least, I can't think of any
> differences that actually results in.
As mentioned in another reply, I wonder about renewing existing
single-DES tickets from 'k5start', whether existing keytabs have
only single-DES entries, and whether there is any technical reason
why preserving the single-DES key is more risky than letting it
> The KDC should only issue tickets encrypted with the new kvno,
Even if a 'k5start' keytab only contains single-DES keys? Even if
a ticket is being renewed? Then perhaps I should generated a new
single-DES key with the same KVNO as the new keys, and add it to
the 'KeyFile' too (as a colleague here mentioned as a
> and after tickets are issued, the KDC will never look at the
> ticket again. This is different for the krbtgt/ service
> principal, since for that, the KDC _does_ need to look at the
> service ticket again after it's issued (for issuing other
Ah then I wonder then about renewals of tickets with single-DES
The notes mentioned above:
* Phase 1: Add new keys to the principal
There is no simple afs principal.
** Crucial details for adding new keys
- The new keys must be added to the afs service principal, as the DES
keys need to continue to be used for already issued tokens.
- The keytab containing a copy of the new keys must contain only the
new keys and not the DES key(s):
> The default encryption types given by the KDC are probably fine,
> as long as single-DES is not one of them."
> Note that the resulting rxkad.keytab file must NOT contain any
> single DES keys (even if the service principal contains a DES
> long-term key, which is okay)."
* Phase 2: Activation of the new key and keytab
At some point the service principal must have both old and new
keys, and the new keys must be activated.
** Crucial details for activation
- The newly created keytab can contain multiple keys and all be looked
> The Kerberos keytab format allows the rxkad.keytab to hold keys
> for both afs/cell@REALM and afs/cell@DOMAIN regardless of their
> respective kvnos. All keys in the rxkad.keytab will be tried for
> decrypting incoming requests,
- The new keys will be used immediately (without any need to restart th=
AFS server daemons) but only for new client connections as clients as=
for new tokens:
> Once the key is changed in the Kerberos database, any new service
> tickets issued to clients (e.g., by running aklog) will be
> encrypted with the new key; AFS servers will be able to decrypt
> the tokens generated from those service tickets as soon as the
> rxkad.keytab file is in place. [ =E2=80=A6 ] Since the KeyFile rema=
> place, existing AFS tokens continue to work."
Therefore connections to the AFS service will fail if:
* They use AFS tokens obtained after the new keys have been added.
* They are made before the corresponding keytabs have
been distributed to the servers and restarted. Thus the
extraction and copy should be as quick as possible:
> make the time gap between generating a new key in the Kerberos
> database and the installation of the rxkad.keytab on the AFS
> servers as small as possible.
- The old KeyFile key will be used for existing connections, including
those among AFS-servers:
> The creation of an rxkad.keytab file only changes the behavior of
> running server processes by allowing them to decrypt incoming
> tokens. Existing server-to-server connections will continue to use
> the preexisting printed tokens,
* bos services must at some point be restarted on all servers:
> so the next step is to use =E2=80=99bos restart -all=E2=80=99 to =
> server-to-server communications. Again, there may be a
> user-visible =E2=80=99blip=E2=80=99 to clients accessing a server=
> processes are restarted. =E2=80=99bos restart -bosserver=E2=80=99=
should not be
> needed at this step.
Note: this will fail if done remotely with a newly issued token,
because the new token will use the new keys, and the existing
daemon processes will only contain the old keys.
* Keep the old DES keys for a significant period:
> For a minimal-impact transition, the old keys in the KeyFile
> should be retained until all existing tokens have expired.
Phase 3: Completion
After the new keys are generated and activated both old DES and new key=
will be used for authentication, as in the rxkad-k5 scheme.
Eventually the old DES key should no longer be used. This can be done b=
making the KeyFile containing its copy unavailable, and then optionally=
purging the DES key from the service principal.
** Crucial details for completion
- The DES key can be removed from the afs service principal only if all=
clients have been upgraded:
> rxkad-kdf, permits the use of non-DES Kerberos session keys and
> removes the dependency on DES in the KDC. Unfortunately, this
> modification requires changes to the OpenAFS client software on
> every machine that makes authenticated connections to the cell.
- The OpenAFS server daemons will reconfigure and as a side effect stop=
using the keys in a removed KeyFile when they detect that CellServDB
> Be sure to run =E2=80=99touch CellServDB=E2=80=99 so that the confi=
> is detected.
> The asetkey utility updates the =E2=80=9Clast modified=E2=80=9D tim=
e on the server
> CellServDB file so that the presence of the new key is detected
- The client caches, as long as they include the rxkad patches (1.4.15,=
1.6.5, or equivalent with backports) don=E2=80=99t need restarting, b=
what matters is the tokens, which are not part of their state:
> Note that the client modifications to accommodate rxkad-kdf do not
> require a restart of the OpenAFS client in order to take effect.
> The modifications only affect the userspace tools used to acquire