FIPS certification

[Nicolas Williams]

On Fri, Feb 27, 2009 at 09:45:21PM -0800, Russ Allbery wrote:
> Randy Turner <rturner at amalfisystems.com> writes:
> > I haven't completely analyzed MIT Kerberos, but I was wondering if it
> > would be possible to get the MIT Kerberos subsystem to use the OpenSSL
> > crypto API for any cryptographic support needed for Kerberos?
> 
> I believe it would be extremely difficult (although maybe someone has made
> changes on this front and I've missed them).  If you want Kerberos
> libraries that use OpenSSL crypto, you'll probably find it easier to just
> use Heimdal, which already does so, than trying to change MIT Kerberos to
> do so.

Wyllys Ingersoll did it for Solaris a few years ago.  In Solaris the
Kerberos stack uses PKCS#11 (in user-land -- the kernel-land crypto
interfaces are different, but in the kernel Kerberos still uses the
Solaris crypto framework, instead of the MIT krb5 crypto code).

The biggest challenge _by far_ is krb5_keyblock.  The size of that
structure is part of the ABI because it was always in a public header
and code used (and still might) allocate krb5_keyblock variables as
automatics.  IIRC its layout too is part of the ABI.

Solaris at the time did not expose a krb5 API, so it was trivial for us
(Wyllys) to change krb5_keyblock and to add initializers for it.  But
when it comes to contributing these changes to MIT we'll run into this
problem.  There are solutions that preserve compatibility with code that
allocates krb5_keyblock on the stack, but they aren't pretty.  Breaking
the ABI could be considered -- it'd be a smallish break, but it won't be
Sun deciding that, but the MIT Kerberos community.

Sun would love for MIT to adopt changes to make MIT krb5 use PKCS#11.
Even using OpenSSL might work for us because we have the OpenSSL PKCS#11
ENGINE.

Nico
--