On 1/23/2014 2:18 PM, Peter Grandi wrote:
[ ... ] 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 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.
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.
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.
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.
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.
smime.p7s
Description: S/MIME Cryptographic Signature
