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

[Jeffrey Altman]

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

On 9/29/2010 1:38 PM, Steve Simmons wrote:
> On Sep 29, 2010, at 12:25 PM, Jeffrey Altman wrote:
>=20
>> 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 firs=
t
>> time what has been suspected for many years: Kerberos for Windows is n=
ot
>> a priority for the Consortium and future development should not be
>> expected any time soon. . .=20
>=20
>> . . . 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?
>=20
> I think your last sentence is a clue. :-)
>=20
> Caveat: I have no actual insight into the MIT kerberos consortium, but =
I've watch MS do business and seen how hard they're pushing Active Direct=
ory and integration between AD and Kerberos. Based on that:
>=20
> IMHO the long-term source of kerberos authentication for windows will c=
ome more and more from Active Directory and ever-closer integration and t=
rust between AD and Kerberos realms. That's the solution Microsoft would =
prefer. Since they're a member of the kerberos consortium they probably s=
wing some weight on the topic.
>=20
> So not only is MIT kfw effectively orphaned, it's deliberately slated f=
or death by neglect. Nor do I see enough demand for it that it would ever=
 be adopted by anyone with enough resources to make it generally useful i=
n the open source world.

I was not intended for this thread to be a discussion of whether or not
there is a need for KFW or Heimdal.  If SSPI by itself was in fact an
option on all of the versions of Windows that we support then it is
something that we would have supported years ago.   Alas it is not.

Here is the problem.  Without a GSS-API implementation on Windows (SSPI
!=3D GSS) there cannot be rxgk.  Without a krb5 implementation on Windows=
,
there cannot be rxk5.  There must be some implementation or we cannot
securely support OpenAFS on Windows.

At the EuroAFS Conference in Pilsen,  Josh Howlett (JANET-UK) commented
on the fact that without a modern supported GSS-API implementation on
the Windows platform it would be impossible to support Project Moonshot.

  http://afs2010.civ.zcu.cz/desc.php?name=3Dmoonshot

The demand for a Windows implementation of GSS-API is clear.  If we do
not have one, then we give up any ability to develop cross-platform
applications and services that utilize the IETF standards for security.

As for which parties are supporting the development of GSS-API on
Windows?  Secure Endpoints, Stanford University, and FermiLab and
every organization that has a support contract with Secure Endpoints.

In Stephen Buckley's e-mail he claims the issue is that no one would
step up and support the Windows platform.  This is absolutely untrue.
Organizations joined the Consortium because KFW was a priority for them.
I worked for two years to obtain a $100,000 grant from the Mellon
Foundation for the Consortium based around the Windows work.  Secure
Endpoints and its clients donated tens of thousands of lines of code.

There is a need for a GSS-API implementation on Windows.  Since the
Consortium won't lead the effort or work with our community to address
its needs, we had to look elsewhere.  Heimdal is a very well respected
implementation that is willing to work with us.  As a result, we now
have an alternate source of GSS-API on Windows to support the needs of
OpenAFS.

>> As part of the conversion to support Heimdal the KFW SDK can be remove=
d
>> 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?
>=20
> Assuming I understand you correctly, you're proposing to remove kfw fro=
m the oAFS distribution, and if this is done, then you'd like opinions on=
 where folks should get the Heimdal compatibility sdk.

I am stating that continuing to build against the MIT KFW 3.2.2 SDK is a
dead-end.  It provides no flexibility to support alternate
implementations of Kerberos and GSS-API, is no longer supported via
upstream.  Continuing to rely on it is a non-starter.

> My answer is somewhat dependent on just what we'd like to see happen wh=
en someone *does* need kfw from this point forward.=20

I'm not sure what you mean by someone needs KFW.  Binaries built against
the Heimdal compatibility SDK are compatible with not only the Heimdal
assemblies but also the MIT KFW 3.2.x and 2.6.x DLLs.  The whole point
of the switch is to provide the user community with an upgrade path
while maintaining full backward compatibility for the currently deployed
Kerberos solution.

If and when there is a version of the Microsoft SSPI that could support
all of the necessary functionality of rxgk and rxk5, the natural place
to put that functionality is in the Heimdal Compat SDK and not into
OpenAFS directly.

> If we're going to make it a separate git repository at oafs.org, then I=
'd say make the Heimdal shims a separately downloadable repository as wel=
l. Conversely, if we direct folks who need kfw to the MIT distribution, i=
t seems both reasonable and consistent to direct those needing the Heimda=
l shims to the github.org repository.

Heimdal has its own repository and the Heimdal Compatibility SDK is a
product of Secure Endpoints which has its own repository.  The question
is not whether OpenAFS should become the upstream repository for Heimdal
or the Compat SDK but whether OpenAFS should import the SDK from
upstream as a means for distributing the OpenAFS approved version to
developers.

> I strongly suspect the size of the community that would need the Heimda=
l shims is small and will shrink over time. Conversely, those sites which=
 are actively downloading and running Heimdal on windows have de-facto de=
monstrated a great deal of savvy on finding and installing software they =
need. As long as we clearly document where they can get the Heimdal shims=
 for oAFS on Windows, having it be a separate load from a separate site m=
akes sense to me.

I believe this would be true only if OpenAFS and NetIdMgr usage
decreases from current levels.

> I therefore would vote to remove KFW from the oAFS repository, and put =
directions to both KFW and the Heimdal shims in the distribution notes.
>=20
> Removing kfw from the standard oAFS git repository also helps reduce th=
e number of things that are 'part of' oAFS and which users might expect u=
s to be supporting. IMHO that's a win. In addition, I think it would resu=
lt in user complaints about kfw going directly to the Consortium. That's =
likely to carry more weight than our second-hand repetition of those comp=
laints.

We do not ship KFW as part of OpenAFS.  Only the KFW SDK is part of the
repo and is only used by developers.  Users already have to obtain KFW
from MIT, Secure Endpoints or their host institution.

> As an aside, note that if we completely remove the kfw distribution fro=
m the openafs.org git repository, there's nothing to say we can't revisit=
 that. Should future versions of oAFS require a kfw that we've fixed and =
if the MIT consortium is unwilling to release those fixes, we should eith=
er add a fixed kfw as a separate git item in openafs.org or include a pat=
ch set that folks could then apply to MIT kfw. I'm not sure which of thos=
e two is preferable, but we can burn that bridge when we come to it. Simi=
lar comments apply to a future in which the Heimdal shims become moribund=
=2E

There are no fixes to KFW that go into the OpenAFS repository as there
is no KFW in the OpenAFS repository.  It is just the headers and
libraries necessary to build OpenAFS.

Jeffrey Altman


--------------enigC6061EC0CEB6F6BC85C9512B
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)

iQEcBAEBAgAGBQJMo4/BAAoJENxm1CNJffh423UH/2ohr+OMRUaKNAVKMhNP9upg
xk3wSq/vBzr8jQcxL9ob1iFzKB0ebr6WfinkQKUjkd57fS/beejPKAJK4Liq9Uet
9iM0L7a1uPv2zw3qnsd2Qrrld9CIIJHHqIYCE1h3gQbvzogrCB8m3Uq3l6prRN9O
nf7AA89kPQikOc7cBsioMSmyyDWHPK1SyrkGsSy+gGE79vPhIUuwIqDjEHYH1SOs
Hr42OMZGMVebIGxshImen1zOmiStLBoxghgldyo5FH2pku/6NCAtXfzR9H6cHOqs
58ZoMyYunODxqiQ+xY3c8QiOljBxmAMPCOPM2Qz8w13yJ8PNjqA1Sv6l5wtVKeY=
=aVP/
-----END PGP SIGNATURE-----

--------------enigC6061EC0CEB6F6BC85C9512B--