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

[Peter Grandi]

I was reviewing in great detail the 'rxkad-{k5,kdf}' upgrade
instructions and in particular the rekeying HOWTO:

http://www.openafs.org/pages/security/how-to-rekey.txt

The default encryption types given by the KDC are probably
fine, as long as single-DES is not one of them. If you want to
specify exactly which encryption types to use, give the -e
option to ktadd. To get the enctypes in the above example, for
kadmin: ktadd -k /tmp/rxkad.keytab -e "aes256-cts-hmac-sha1-96:normal aes128-cts-hmac-sha1-96:normal des3-hmac-sha1:normal arcfour-hmac-md5:normal" afs/cell
Entry for principal afs/cell with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/tmp/rxkad.keytab.
Entry for principal afs/cell with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab WRFILE:/tmp/rxkad.keytab.
Entry for principal afs/cell with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/tmp/rxkad.keytab.
Entry for principal afs/cell with kvno 3, encryption type ArcFour with HMAC/md5 added to keytab WRFILE:/tmp/rxkad.keytab.

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

kadmin.local: addprinc -policy service -randkey -e "des-cbc-md5:normal" test
Principal "***@TY.SABI.CO.UK" created.

kadmin.local: getprinc test
[ ... ]
Number of keys: 1
Key: vno 1, des-cbc-md5, no salt
[ ... ]

kadmin.local: ktadd -k /tmp/test.kt -e "aes256-cts-hmac-sha1-96:normal" test
Entry for principal test with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/test.kt.

kadmin.local: getprinc test
[ ... ]
Number of keys: 1
Key: vno 2, aes256-cts-hmac-sha1-96, no salt
[ ... ]

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:

http://web.mit.edu/kerberos/krb5-current/doc/admin/advanced/retiring-des.html

This will result in the existing single-DES key to remain, and
for the new keys to have a KVNO one higher than it. Then one
must use 'ktadd -norandkey' to create the keytab.

But this adds *all* keys to the keytab, including the single-DES
key, and the single-DES key is added to the keytab with an
incremented KVNO, *even if* the KVNO of the single-DES key's
KVNO is not incremented in the KDB:

kadmin.local: addprinc -policy service -randkey -e "des-cbc-md5:normal" test
Principal "***@TY.SABI.CO.UK" created.

kadmin.local: getprinc test
[ ... ]
Number of keys: 1
Key: vno 1, des-cbc-md5, no salt
[ ... ]

kadmin.local: cpw -randkey -keepold -e "aes256-cts-hmac-sha1-96:normal" test
Key for "***@TY.SABI.CO.UK" randomized.

kadmin.local: getprinc test
[ ... ]
Number of keys: 2
Key: vno 2, aes256-cts-hmac-sha1-96, no salt
Key: vno 1, des-cbc-md5, no salt
[ ... ]

This is as desired, but then:

kadmin.local: ktadd -k /tmp/test.kt -norandkey -e "aes256-cts-hmac-sha1-96:normal" test
cannot specify keysaltlist when not changing key

kadmin.local: ktadd -k /tmp/test.kt -norandkey test
Entry for principal test with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/test.kt.
Entry for principal test with kvno 2, encryption type des-cbc-md5 added to keytab WRFILE:/tmp/test.kt.

kadmin.local: getprinc test
[ ... ]
Number of keys: 2
Key: vno 2, aes256-cts-hmac-sha1-96, no salt
Key: vno 1, des-cbc-md5, no salt
[ ... ]

# klist -k /tmp/test.kt -e
Keytab name: FILE:/tmp/test.kt
KVNO Principal
---- --------------------------------------------------------------------------
2 ***@TY.SABI.CO.UK (aes256-cts-hmac-sha1-96)
2 ***@TY.SABI.CO.UK (des-cbc-md5)

That means that the keytab just created contains an entry for a
non existent key. Easy to delete with 'ktutil', but can cause
problems. Indeed there was a report in the #OpenAFS IRC channel
about the presence of a DES key in the keytab causing failure:

[06:20] chrisb | any comments on the upgrade procedure for
server 1.6.2? i find it difficult
[06:20] chrisb | bos: failed to restart servers (ticket
contained unknown key version number)
[06:32] chrisb | ok, working now. i had left des-enctypes
in the .keytab

I suspect that the presence of single-DES keys in 'rxkad.keytab'
is not itself an issue, the issue is that it has an incremented
KVNO that is higher than that of the key in the KDB is the
problem.

Looks to me There is a bug in the MIT Kerberos 'ktadd -norandkey'.

[Benjamin Kaduk]

Hi Peter,

Post by Peter Grandi
I was reviewing in great detail the 'rxkad-{k5,kdf}' upgrade
http://www.openafs.org/pages/security/how-to-rekey.txt

I wrote the majority of both this document and the 'retiring des' document
mentioned later.

Post by 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.

Post by Peter Grandi
single-DES tokens and client to stop working as the key in the

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. So long as the key remains in the KeyFile on the AFS servers,
the ticket (and thus token) can be verified.

Post by Peter Grandi
To avoid this one has to use 'kadmin.local' to be able to use
'cpw -keepold' and 'ktadd -norandkey', as advised in the MIT

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. Can you clarify a bit more why you
believe it is necessary to preserve these keys in the KDB?

Post by Peter Grandi
But this adds *all* keys to the keytab, including the single-DES
key, and the single-DES key is added to the keytab with an
incremented KVNO, *even if* the KVNO of the single-DES key's
kadmin.local: addprinc -policy service -randkey -e "des-cbc-md5:normal" test
kadmin.local: getprinc test
[ ... ]
Number of keys: 1
Key: vno 1, des-cbc-md5, no salt
[ ... ]
kadmin.local: cpw -randkey -keepold -e "aes256-cts-hmac-sha1-96:normal" test
kadmin.local: getprinc test
[ ... ]
Number of keys: 2
Key: vno 2, aes256-cts-hmac-sha1-96, no salt
Key: vno 1, des-cbc-md5, no salt
[ ... ]
kadmin.local: ktadd -k /tmp/test.kt -norandkey -e "aes256-cts-hmac-sha1-96:normal" test
cannot specify keysaltlist when not changing key
kadmin.local: ktadd -k /tmp/test.kt -norandkey test
Entry for principal test with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/test.kt.
Entry for principal test with kvno 2, encryption type des-cbc-md5 added to keytab WRFILE:/tmp/test.kt.
kadmin.local: getprinc test
[ ... ]
Number of keys: 2
Key: vno 2, aes256-cts-hmac-sha1-96, no salt
Key: vno 1, des-cbc-md5, no salt
[ ... ]
# klist -k /tmp/test.kt -e
Keytab name: FILE:/tmp/test.kt
KVNO Principal
---- --------------------------------------------------------------------------
That means that the keytab just created contains an entry for a
non existent key. Easy to delete with 'ktutil', but can cause
problems. Indeed there was a report in the #OpenAFS IRC channel
[06:20] chrisb | any comments on the upgrade procedure for
server 1.6.2? i find it difficult
[06:20] chrisb | bos: failed to restart servers (ticket
contained unknown key version number)
[06:32] chrisb | ok, working now. i had left des-enctypes
in the .keytab
I suspect that the presence of single-DES keys in 'rxkad.keytab'
is not itself an issue, the issue is that it has an incremented
KVNO that is higher than that of the key in the KDB is the
problem.

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. 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.
This is particularly bad if the krb5 implementation on some (other) server
will pick a key from the keytab in a fashion that does not take into
account the strength of the various enctypes -- we have seen cases where a
"printed token" used for server-to-server authentication ends up picking a
single-DES key from rxkad.keytab (even when an AES enctype is available),
and this causes server-to-server authentication to fail if the single-DES
key is not also in the KeyFile.

Post by Peter Grandi
Looks to me There is a bug in the MIT Kerberos 'ktadd -norandkey'.

It does, thank you for the report. I will look into it more closely.
Do I understand correctly that you see this behavior from ktadd -norandkey
in both MIT krb5 1.8 and 1.10?

Thanks,

-Ben Kaduk

[Peter Grandi]

[ ... ]

Post by Benjamin Kaduk

Post by 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.

Post by Peter Grandi
single-DES tokens and client to stop working as the key in the

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.

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

Post by Peter Grandi
To avoid this one has to use 'kadmin.local' to be able to use
'cpw -keepold' and 'ktadd -norandkey', as advised in the MIT

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?

Post by Benjamin Kaduk
[ ... ] 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.

Post by Benjamin Kaduk
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.

Post by Benjamin Kaduk
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 :-).

[Andrew Deason]

On Thu, 23 Jan 2014 18:35:40 +0000

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

You apparently get a keytab that contains DES keys in it, and apparently
the DES entries have the wrong kvno. That can cause problems. That's the
only actual problem I can think of, besides just being confusing.

If the KDC does actually use that old key for issuing a new ticket, then
that could also be a problem. But I'm not aware of any case in which it
does, which also means keeping it around is pointless.

There's also no way to get rid of it unless you are running a new enough
MIT KDC. I don't remember what version lets you fix that, but istr older
ones have no way of removing older keys besides hex-editing the database
or something crazy like that.

Post by Peter Grandi
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

I don't think that's possible. Someone more familiar with the MIT KDC
codebase can confirm/deny, but old kvnos should be ignored for the
purposes of issuing new tickets; I don't know of any situation where
that's not true.

What you would really want to look for is incoming requests to the AFS
servers that are using single-DES keys. But I don't think we have a way
of tracking that beyond sniffing the wire traffic.

Post by Peter Grandi
"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.

Oh, we just like to be cautious. I hear Kerberos and OpenAFS have a
large number of corner cases ;)

But yes, it's helpful to keep around in case someone is still using
those credentials. This can be already-issued tokens, or it can be any
machine that has a copy of the KeyFile, and is using it for outgoing or
incoming connection authentication.

Post by Peter Grandi
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.

It doesn't. It just runs aklog to get tokens, which will take your TGT,
and acquire an afs/ service ticket with it. The keys in such a keytab
are only for obtaining a TGT (in this situation), and the TGT is used
for obtaining other service tickets.

Also, I'm not sure if this is clear, but the encryption type of the
service key is supposed to be invisible to the client; the client just
passes an encrypted blob to the server. The keys in your keytab for a
k5start'ified service have no relation to the keys for the afs/ service
principal. (Unless you are trying to authenticate _as_ the afs/
principal, which is weird and you're on your own.)

It also should be pointed out that this general rekeying procedure isn't
really an AFS thing. It was just provided for the rxkad-k5/kdf
transition, since it was my opinion that many sites have never performed
a rekeying procedure and wouldn't know what to do. The "basic" procedure
we described is the same as rekeying any kerberized service, and matches
the procedures recommended by the MIT link you provided (for kerberized
application services, not the TGS). So if you want to change what the
recommended procedure for rekeying services is, I think you'll need to
convince the general Kerberos community and not us.

There are some specifics with the KeyFile and rxkad.keytab and all that,
but the how-to-rekey.txt document itself I believe is largely agnostic
of the underlying service. We talk about the afs/ service principal and
fileservers and such so we can be more direct and less confusing, but
the actualy procedures are not AFS-specific.

Post by Peter Grandi

Post by Benjamin Kaduk
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 :-).

Yes, and doing this is what is recommended.

[Andrew Deason]

On Thu, 23 Jan 2014 16:36:18 +0000

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,

That is intentional and expected.

which probably results in existing single-DES tokens and client to
stop working as the key in the 'KeyFile' is no longer matched by one

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 is expected, and noted in the "Basic procedure". Using one of the
other rekeying procedures allows you to reduce or eliminate the amount
of time where authentication is broken.

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
http://web.mit.edu/kerberos/krb5-current/doc/admin/advanced/retiring-des.html

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. The
KDC should only issue tickets encrypted with the new kvno, 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).


If you're looking to avoid the "authentication breaks" period while
still doing something like the "Basic procedure", you would need to be
able to 'cpw -keepold', but disable the new non-DES keys. Then you could
extract the keys into a keytab, distribute them, and then enable the new
non-DES keys and disable or delete the old DES keys. I'm not aware of a
way to do with that an MIT KDC; if that's possible, it would be rather
new, I think.

The "ktutil procedure" in the rekeying document does basically that,
though; it's just that the new non-DES keys are not stored on the KDC
until the final step when you enable them.

Looks to me There is a bug in the MIT Kerberos 'ktadd -norandkey'.

Yeah, it does looks like it gives you the wrong kvno when you have
multiple kvnos for the princ. That shouldn't be impacting this
procedure, though.

[Peter Grandi]

Post by Andrew Deason

[ ... ] 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.

Post by Andrew Deason
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.

[ ... ]

Post by Andrew Deason
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.

Post by Andrew Deason
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).

Post by Andrew Deason
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

Post by Andrew Deason
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

Post by Andrew Deason
The Kerberos keytab format allows the rxkad.keytab to hold keys
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

Post by Andrew Deason
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

Post by Andrew Deason
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

Post by Andrew Deason
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,
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.

Post by Andrew Deason
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

Post by Andrew Deason
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

Post by Andrew Deason
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

Post by Andrew Deason
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.

[Jeffrey Altman]

Post by Peter Grandi

Post by Andrew Deason

[ ... ] 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
upgrade procedures.

It isn't always ok to remove the DES key from the KDB. Some KDCs will
not issue a DES session key if there is no DES key present for the
service principal. The language is ambiguous and wishy-washy because
the fact is that the capabilities and limitations of the KDC in question
matter and the variances are not only across implementations such as MIT
vs Heimdal but also which major/minor release of the same and which OS
distribution it was packaged with.

Post by Peter Grandi

Post by Andrew Deason
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.

[ ... ]

Post by Andrew Deason
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.

KDCs can only renew initial tickets which are typically ticket granting
tickets. You can explicitly request an initial service ticket but that
is rare. If there is a keytab with a DES key being used with k5start
then that is a DES key for the client principal which is independent of
the AFS service principal. A DES key for a client principal has its
own set of risks. DES keys for clients should be removed for different
reasons.

From an AFS perspective there is no harm in keeping a DES key in the KDB
provided that the KDC will not issue a ticket using it. A KDC's choice
of server ticket enctype should not be capable of being manipulated by
the client issuing the request. We know that isn't true but it
shouldn't be true. If your KDC is one of the ones that can be
manipulated by the client, then you should upgrade/replace it.

Post by Peter Grandi

Post by Andrew Deason
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).

The k5start keytab should be for a client principal not the AFS principal.

Post by Peter Grandi

Post by Andrew Deason
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.

See above.

[Benjamin Kaduk]

Sorry for the delayed response. It looks like Jeffrey's and Andrew's
responses should have addressed the major issues.

It would also be a little easier for me if the attribution of who wrote
the quoted text was retained.

Post by Peter Grandi
** Crucial details for completion
- The DES key can be removed from the afs service principal only if all

I don't believe this is exactly right, with the note that to me "afs
service principal" means "the keys in the KDB". Once a service ticket has
been issued by the KDC (encrypted in the long-term key of the afs service
principal, which is shared between the AFS servers and the KDC), the KDC
is not involved anymore (barring the rare case of initial tickts directly
for the afs service principal which Jeffrey mentioned in passing; this
would involve the -I and -S arguments to k5start). The normal workflow
does not involve material encrypted in the afs service principal's
long-term key coming back to the KDC. Even if you are concerned that
initial tickets for the afs service principal are in use, you only need to
wait for the maximum renewable lifetime to pass after creating the new
keys before removing the old ones; the status of client software is not
relevant at all.

Post by Peter Grandi
- 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

The client caches don't even need the rxkad patches. An aklog binary (or
whatever binaries are used to obtain tokens) from 1.4.15 with the rest of
the cache manager from 1.4.14 (or older) is sufficient to gain the
benefits of rxkad-kdf.

-Ben