Sean O'Malley wrote: > I was also thinking that you could hack kaserver to store client keys,
The Kerberos database already stores client keys. Those keys are what are used to authenticate the user. A new session key known only to the AFS servers and the user is then obtained from Kerberos and that is used to authenticated and protect the non-authenticated connections between the cache manager and the AFS servers. That is how things are done today. The problem today is that there is no key available for anonymous connections. > and transport encryption keys. It could store the client public user key > to match it with the host key and an encryption key. (and of course put a > TTL on those keys so they can be cleaned up periodically, and for > security.) Which does require another server, but kaserver would > just need to be modified. (well okay, it probably needs to be completely > overhauled, but not for a prototype.) There is no need to add public key cryptography in place of Kerberos. Kerberos already does what we need for authenticated connections. > Thus I have offered more confusion. :) You are doing a good job of it. :) ---- There are two different sets of communications that you need to be concerned with. First there is the communication path between the application and the AFS cache manager. This is not authenticated by Kerberos but instead is a local system authentication. This communication path is then used to store a token into the cache manager. The token is used to perform authentication with the AFS servers for requests on behalf of the user. When the token is stored it is bound to the local user identity within the cache manager. The cache manager keeps a shared copy of all file/directory status and content in the cache for all users. Part of the information that is cached are the ACLs. If you want to protect the content of the cache, then it must be encrypted with a key that is known not to any user but to the cache manager. Hence, my recommendation that you turn on encryption of the cache directory. Doing so will ensure that only the account under which the AFS Cache Manager runs will be able to read or write data from the cache. The AFS Cache Manager is disconnected mode (when that is available) will locally restrict access to files based upon the AFS ID and the directory ACLs. Only users that are permitted to access the data based upon its last known state would be permitted to do so. You don't need additional keys for this. If your local system authentication is strong, then only the locally authenticated user will be able to communicate with the cache manager using the identifiers for the user that are seen by the cache manager. Without a valid token, the cache manager will not be able to write data back to the server on behalf of the user. That is a limitation that disconnected mode will have to address. Jeffrey Altman Secure Endpoints Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
