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

[Peter Grandi]

>> [ ... ] 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 th=
e
  AFS server daemons) but only for new client connections as clients as=
k
  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=
ins 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 =E2=80=99bos restart -all=E2=80=99 to =
refresh the
    > server-to-server communications. Again, there may be a
    > user-visible =E2=80=99blip=E2=80=99 to clients accessing a server=
 when its
    > 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=
s
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=
y
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 =E2=80=99touch CellServDB=E2=80=99 so that the confi=
guration change
  > 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
  > immediately

- 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=
ecause
  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.