On Wed, 4 Sep 2013, Benjamin Kaduk wrote:
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).
I thought Simon had replied to this, noting the existince of service-specific data in our RX implementation, but I can't find it in mail or jabber logs.
Anyway, I finally got around to prototyping a solution using rx service-specific data to hold the getkey routine and rock, and it seems to work pretty well -- I think it's less code than the approach from the quoted text.
It does seem like we'll want to expose some rxgk-specific API that's a conglomeration of NewServerSecurityObject, NewService, and SetServiceSpecific, so that there's a single API call for setting the getkey function and rock for a given server process. (The getkey function used to get a key to encrypt tokens needs to match the getkey function used to decrypt those tokens when they're presented in an rx response.) In my prototype I called it rxgk_NewService_SecObj, but that's hardly a great name.
I also prototyped an "ephemeral" version of the same API that generates a random key and just produces a copy of it from the getkey routine.
A couple links to commits from the 'rxgk' branch on my github: https://github.com/kaduk/openafs/commit/25d5767d45236a89529 https://github.com/kaduk/openafs/commit/6e64c41c993af05d0e5 -Ben _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
