[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