[OpenAFS-devel] Building OpenAFS for Windows with Heimdal Compatibility

Jeffrey Altman jaltman@secure-endpoints.com
Wed, 29 Sep 2010 12:25:05 -0400


This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5B8E73BDA19AF2935FE1DDD2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

 The last release of Kerberos from MIT for Windows was issued nearly
three years ago.  In an e-mail to krbdev@mit.edu on 11 August 2010,
Stephen Buckley (MIT Kerberos Consortium) stated publicly for the first
time what has been suspected for many years: Kerberos for Windows is not
a priority for the Consortium and future development should not be
expected any time soon. The thread can be read at

  http://comments.gmane.org/gmane.comp.encryption.kerberos.devel/8829

In order for OpenAFS to migrate to a new Rx security class that supports
AES instead of fcrypt, we must have a Kerberos implementation available
that exports the functionality required.   The existing KFW 3.2.2
release does not meet the future requirements and has compatibility
issues with Windows 7 and Server 2008.  Due to the lack of support from
MIT, Secure Endpoints began a project nearly 18 months ago to port
Heimdal to the Windows platform.

As announced in Pilsen CZ, Heimdal 1.4 now contains support for the
Microsoft Windows platform.  Secure Endpoints is preparing to release
binary installers for Heimdal along with Network Identity Manager and
its credential providers that work with both Heimdal and KFW.   However,
for OpenAFS users the Heimdal distribution will be useless until the
OpenAFS distributions are updated to build with Heimdal support.

The Heimdal and MIT application programming interfaces not to mention
the application binary interfaces are are different.  It is not possible
to use the existing OpenAFS distributions with Heimdal.  Asanka Herath
has developed a compatibility library that is based upon ideas from Russ
Allbery.=20

  http://github.com/secure-endpoints/heimdal-krbcompat

When applications are built against this compatibility library, those
applications will prefer Heimdal but will fallback to either MIT KFW
3.x.x or 2.6.x.  This permits the applications to be deployed today
while allowing sites to determine on their own whether or not to replace
MIT KFW with Heimdal.

Back in 2003 when Kerberos v5 support was added to OpenAFS for Windows,
the MIT KFW SDK was imported into the source tree under src/WINNT/kfw.=20
This was done to avoid the need for developers to download and install
yet another SDK in order to build the source tree.  Another benefit of
this approach is that all OpenAFS builds are built against the proper
version of the SDK to ensure maximum backward compatibility.

As part of the conversion to support Heimdal the KFW SDK can be removed
from the OpenAFS repository.  The question that remains is how should
Windows developers obtain the Heimdal Compatibility SDK?

   1. Should it be imported into the OpenAFS repository from github as
      an external?
   2. Should it be required that developers download it and install it
      themselves?

I am fine either way.  I do not want to see the build scripts require
git on the build machine to download the package at build time as that
will fail for some large institutional users that build from source.

What do you think?

Jeffrey Altman







--------------enig5B8E73BDA19AF2935FE1DDD2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJMo2hjAAoJENxm1CNJffh4zksIAIrG1Gn9zAYHMRe3XNwg9L01
94Q4hWVxpmAF+9FgiEcK8varQ+3KpBbRiRm5m8ubz+0eXu2xswCVAvIUVe2w+MSo
6i2c9lpw0NNp8kzp3CxXcO7FMRThsMNHifiZA0h0N/DV9OfirUM76V8LYFHQ9pln
R2gSgTa6oclA50GhO72M9xuBMg6RwnayVM7uHjOdcrZlLlrXvGBpCPtqEk4Qvl+T
KVl+/DsNL3W70v5xPZNzblQFGYtwKjdn/cEg9XU+/3N9578veBI/KC/4RVcGZyGg
P5cNH5mJJy0zvnJ3tW1Qe4T3KrtncK4NgvNVRa63DtCByyqhijIkbuEvwbX6BuQ=
=Srh+
-----END PGP SIGNATURE-----

--------------enig5B8E73BDA19AF2935FE1DDD2--