>> [ ... ] 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
example:
"(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
upgrade procedures.
> 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
go.
> 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
possibility).
> 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
> tickets).
Ah then I wonder then about renewals of tickets with single-DES
keys.
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
at:
> 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 the
AFS server daemons) but only for new client connections as clients ask
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. [ … ] Since the KeyFile remains in
> 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,
Therefore:
* bos services must at some point be restarted on all servers:
> so the next step is to use ’bos restart -all’ to refresh the
> server-to-server communications. Again, there may be a
> user-visible ’blip’ to clients accessing a server when its
> processes are restarted. ’bos restart -bosserver’ 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 keys
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 by
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
is modified:
> Be sure to run ’touch CellServDB’ so that the configuration change
> is detected.
> The asetkey utility updates the “last modified” time on the server
> CellServDB file so that the presence of the new key is detected
> immediately
- The client caches, as long as they include the rxkad patches (1.4.15,
1.6.5, or equivalent with backports) don’t need restarting, because
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
> tokens.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
