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

[Benjamin Kaduk]

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---559023410-1166057031-1390589333=:27579
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-7; FORMAT=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <alpine.GSO.1.10.1401241349071.27579@multics.mit.edu>

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

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

On Thu, 23 Jan 2014, Peter Grandi wrote:

> ** Crucial details for completion
>
> - The DES key can be removed from the afs service principal only if all
>  clients have been upgraded:

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

>
> - The client caches, as long as they include the rxkad patches (1.4.15,
>  1.6.5, or equivalent with backports) don=A2t need restarting, because
>  what matters is the tokens, which are not part of their state:

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

-Ben
---559023410-1166057031-1390589333=:27579--