[OpenAFS-devel] configurable cryptosystem support

Jeffrey Hutzelman jhutz@cmu.edu
Thu, 18 Jan 2007 19:22:47 -0500


On Thursday, January 18, 2007 07:09:25 PM -0500 Marcus Watts 
<mdw@umich.edu> wrote:

> One of the original charges the openafs folks defined for "rx + k5" was
> that it had to not depend on any external library.

I'm not sure who said that.  It certainly was never realistic, and I 
_really_ don't want to see a brand-new complete Kerberos implementation in 
OpenAFS.  A dependency on an existing implementation is a much better 
route, in terms of both completeness and maintainability.

> So far as "RFC 3961" +/- features goes -- the s2k functions in those are
> only needed for initial authentication, and are never needed in the
> kernel. So k5ssl provides that as a separate module that isn't built for
> the kernel.

That seems like a reasonable approach.

> RFC 3961 defines a "pseudo-random" function for each crypto
> system.  I would dearly love to use that in rxk5 - but I don't know of
> any public implementation, entry points, or test vectors.

Indeed, there don't seem to be any.  So, help us to correct that 
deficiency.  I'm sure there are implementors who would be happy to help 
produce test vectors.

> RFC 3961 contains a set of 'assigned numbers' for crypto systems,
> but specifically omits any mention of which ones might be "required".

Right.  RFC3961 is a toolkit; it is up to the application using it to tell 
you which tools are required.  In the case of Kerberos, this is specified 
in section 8.1 of RFC4120, which requires AES256-CTS-HMAC-SHA1-96 and the 
corresponding cksumtype HMAC-SHA1-96-AES256.  It also recommends support of 
DES-CBC-MD5 and DES3-CBC-SHA1-KD, and their corresponding cksumtypes 
DES-MD5 and HMAC-SHA1-DES3-KD.


BTW, I do wish you would configure in terms of the standard enctypes, 
rather than configuring the underlying algorithms.

-- Jeff