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

[Andrew Deason]

On Thu, 23 Jan 2014 16:36:18 +0000
pg@afs.list.sabi.co.UK (Peter Grandi) wrote:

> 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
> in the KDB:

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
> "Retiring DES" HOWTO:
> 
>   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.

-- 
Andrew Deason
adeason@sinenomine.net