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
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
