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
