[OpenAFS-devel] providing key material for rxgk token negotiation

[Benjamin Kaduk]

rxgk introduces a new requirement for the server('s security class) in the 
form of a token negotiation service.  Since it needs to be bootstrappable, 
the negotiation service must be available over rxnull connections, which 
means that the server process must have the rxgk key material available 
when processing RXGK_GSSNegotiate requests over rxnull connections (the 
key material is needed in order to encrypt the blob which will be used as 
the token returned to the client).  It seems like there are two general 
approaches to this problem: (1) extend the rxnull security object to 
include some extra state used to support bootstrapping other security 
classes, and (2) keep some library-internal state, with a library routine 
to register what key material to use (most likely, a callback to get a 
key).

We took something like approach (2) for rxkad-k5 (on 1.6 and 1.4), with 
rxkad_SetAltDecryptProc() and friends, but avoided needing to set 
library-internal state like that for the rxkad-k5 code on master.  I have 
implemented (1) for my stub rxgk client/server test programs on my github 
'rxgk' branch, with the relevant bits mostly in 
https://github.com/kaduk/openafs/commit/9619112a769a56ac02c2894b9e848ea8df763aa7

It seems to me that (1) is a bit more flexible, in that it would allow 
a single server process to provide multiple services that use different 
key material by providing different security objects to the rx_NewService 
calls, but I figured I would run the question by people at an early stage 
so I don't go too far down path (1) if there is objection to it.

The rxnull extension I propose is not rxgk-specific; the new privateData 
structure used for rxnull security objects is a container that contains 
per-security-class fields and a mask for which of those fields are valid. 
Perhaps the mask is not even needed, and non-NULL-ness is sufficient.

Thanks,

Ben