Hi all, Simon and I got a lot of time to chat last week at the EAKC. (Hooray!)
In particular, Simon had a few ideas for how to render SetCallBackKey unnecessary (one of which is used by YFS), and neither of us particularly like having the RPC around.
The summary after analysis is: with the current SetCallBackKey, the file server must maintain a mapping of PrAuthName<>s to (key, token) pairs (though the token can be empty if the CM wishes it to be). This mapping is used when creating callbacks as a result of RPCs during normal operation, and the PrAuthName<> being looked up is one that was cached in the server connection state, since the name vector comes from the token, which is only seen in the rx response. This is the important part, that data from the response must be cached in the server connection state.
But there's no real reason to involve an extra lookup -- the (key, token) pair could itself be stored in the server connection state, and all callbacks generated as a result of that connection would use that callback key. It turns out that we have a built-in way to get application-specific data into a response packet -- the 'appdata' field of the authenticator. Currently rxgk-afs just sets that to the CM uuid, but it could also include a key/token (and also the uuid of the server we're trying to talk to, as an extra consistency check). The file server can pull the key/token from the authenticator and cache it directly.
Alternatively, we could keep SetCallBackKey but require that it be called on a connection before any secure callbacks are issued on that connection, and have the key that is set apply only to that connection (again, being cached in the server connection state). There would need to be some thought about when the key comes into effect and what sequencing guarantees are made, though, so this approach seems less interesting to me.
I plan for the next upload of draft-wilkinson-afs3-rxgk-afs to take the first approach, omitting RXAFS_SetCallBackKey and putting key information in the appdata field. The token format will change back to having just a single list of identities (but the key combination portion will remain unchanged, for the same reasons it is currently present).
-Ben _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
