[OpenAFS-devel] crypto backend and integration for rxgk

[Benjamin Kaduk]

On Wed, 1 May 2013, Jeffrey Altman wrote:

> 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.

(I assume this is scoped to "Windows".)

>> 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?

Necessary is debatable.  Desirable, well, all the reasons Debian tries 
hard to eliminate bundled libraries.  The kernel's crypto library (or even 
an openssl krb5 backend) will offer aesni acceleration, which hcrypto does 
not.

I'm all for the initial implementation being hcrypto-only, but I think 
that it makes sense to leave room for future expansion.

-Ben