8 * Using the vldb document as a guide, design a vldb extension to store per-fileserver token-encrypting keys

9 * [partially in gerrit] Make the afsconf changes needed to allow rxgk server security objects (there must be a way to select which getkey function is used, since not all rxgk-capable servers will use the cell-wide key for token encryption)

10 * [some changes in gerrit] Make the afsconf changes needed for producing rxgk client security objects (the target service is needed in order to perform GSS negotiation against the correct GSS acceptor name, or to choose which long-term key to use if printing a token) (Do we also want to expose a hook for the client identity?)

11 * [in gerrit] Use rxgk for ubik synchronization connections -- these will use printed tokens and do not need any GSS bits

13 * Design a scheme for storing the per-fileserver token-encrypting keys, presumably on disk as these really should accept tokens across restarts. Current proposal is to use keys of a new type, afsconf_rxgk_fs, in KeyFileExt. Some minimal support is implemented by kaduk.

14 * Decide what we want combined tokens to mean. Do we allow combinations with more than two identities? Are combined tokens to be used as the intersection of identities, or the union? Can we do both somehow?

16 * Review the existing pthread-bos code on gerrit -- bos is a nice simple standalone protocol to play with rxgk-ifying, but it is only possible for the pthreaded version.

17 * Decide whether the bosserver should use an ephemeral token-encrypting key. There are no long-lived connections to the bosserver and this would save on the hassle of putting another key on disk, but it makes localauth more complicated. Absent a scheme to print initiator credentials from given acceptor credentials (could be done for krb5 with a sort of kimpersonate), we probably have to do a real GSS negotiation, which depends on the network and everything being configured properly.

18 * ~~Move rx epoch and cid generation into the core rx code (out of rxkad). This will require some thought to seed the rfc3961 crypto random generator in the kernel on platforms which do not already implement in-kernel randomness (maybe just HPUX or something like that?). An attempt at this is at https://github.com/kaduk/openafs/commits/epoch but that branch has been overtaken by events in terms of rfc3961 support, I (kaduk) believe. Update: kaduk will try picking this up again.~~ This is in gerrit, changes 10840-10843.

19 * Teach asetkey to produce a random key in the KeyFileExt to be used as the cell-wide token-encrypting key.

20 * gklog (or additions to aklog?) to get a user token and shove it into the kernel. This will probably require more pioctls and changes to how tokens are stored in the kernel. kaduk has a dummy implementation of a gklog.

21 * There is still much to do in getting a smooth transition plan that does not involve a significant number of steps.