On 5/1/2013 12:24 PM, Benjamin Kaduk wrote: > While doing development work for rxgk, I have just been using dummy > userspace applications as client and server, backending to libkrb5 for > the RFC3961 crypto operations. Obviously this is not a general solution > for the crypto, as libkrb5 is not available in the kernel, and I am > given to understand that the team working on the Windows client would > really like to avoid having to link libkrb5 everywhere. (I didn't get > an understanding of why, but that seems off-topic for this discussion.)
The answer is very straight forward. MIT's Kerberos is not a requirement for use of OpenAFS. Once we are GSS it should be possible to run simply with the Microsoft SSP and the LSA where there is no libkrb5 at all. Heimdal's libkrb5 as you note below is not compatible. Similarly, there is no libkrb5 in kernel and when RX is implemented as a protocol under WinSock in-kernel it will not have access to userland Kerberos libraries. > Furthermore, it seems like we have been going down the path of importing > such bits of hcrypto as we need for functionality, and the expectation > is that we will import more of hcrypto for rxgk support. Correct. > On the other > hand, things which already link against libkrb5 should perhaps not also > link against the in-tree hcrypto, and could use libkrb5 for their rxgk > crypto as well. (An external libkrb5 with an enctype that is not > available in our in-tree hcrypto seems possible, but unlikely to be a > compelling use.) > The incompatibility between heimdal's libkrb5 and MIT's libkrb5 also > comes into play. I see no reason to avoid use of openafs hcrypto at the rx security class layer and libkrb5 at some higher application layer. The fact is that in a world of dynamic libraries it is not possible to prevent more and one version of crypto from being loaded into a process. If my process loads a python module built against one version of a shared library and a perl module built against a different version both will be in the process space. On Windows providing support for this scenario is why I have pushed for the packaging and distribution of kerberos and gss libraries as assemblies. > As such, it seems like we should have the ability for an rxgk-using > tool/utility/etc. to use either hcrypto or libkrb5 for its crypto > backend. This would also leave open the possibility of using an OS > kernel's crypto implementation instead of hcrypto, though that would > require per-OS work and is not needed for an initial implementation. What is the scenario that you are trying to support that makes this necessary and desirable? Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
