Windows future

[Jeffrey Altman]

On 8/11/2010 9:06 PM, Stephen C Buckley wrote:
> Hi Jeff,
> 
> I owe the community an explanation, so here goes.
> 
> The short answer is, that it is up in the air.  For many years, MIT privately put quite a lot of resources into funding development of KfW and NIM.  When we formed the Kerberos Consortium, things changed.  Suddenly, we had an open source project for Kerberos and, additionally an organization with members who invested both money and developer time.   I think it was great that MIT Kerberos was important enough to them that they were willing to provide resources.  It also forced us to do some prioritization.

MIT Kerberos v5 has been an open source project since before
version 1.0 was distributed in 1996. While it is true that MIT has been
the largest direct contributor to the Kerberos distribution since DEC
and IBM funded Project Athena, there have also been many other
organizations and individuals that have contributed source code and money.

However, MIT was not a significant funding source for the Network
Identity Manager work.  The funding for the initial version of NIM
included with KFW 3.0 was provided by Jet Propulsion Lab and Secure
Endpoints.  The improvements in KFW 3.1 were funded by Fermi National
Lab as part of the KCA plug-in development project.  The improvements in
3.2 were funded by Stanford University.  These contributions were
credited in MIT's release announcements for KFW.

> Although there are many institutions for whom KfW and NIM are very important, no one thus far has stepped forward, either as an organization or as an individual, and said that they feel strongly enough about either to enable  the work required to continue to make this a viable platform.

NIMv2 was developed by Secure Endpoints with financial and collaborative
support from Stanford University and Fermi National Labs.  As announced
on 19 Feb 2010, Secure Endpoints has made Network Identity Manager v2.0
freely available for use by the MIT Kerberos Consortium.

In addition, Secure Endpoints along with Stanford University, Carnegie
Mellon University, Jet Propulsion Laboratory and Fermi National Lab were
the entities that actively petitioned the Andrew W. Mellon Foundation in
2007 and 2008 for the Mellon Award for Technology Collaboration on
behalf of "Network Identity Manager", a project of the MIT Kerberos team.

http://web.archive.org/web/20071002170417/matc.mellon.org/2007_nominations/massachusetts-institute-of-technology

This effort resulted in the $100,000 award that the Consortium accepted
from Vint Cerf in 2008.

To say that no one has thus far stepped forward is really disingenuous.

> There are choices.  People could rally behind KfW and NIM and do work.  People could provide the resources that would enable the Kerberos Consortium to do the work.  People could wait and see if the perfectly good Kerberos implementation native to Windows becomes an option.  People could continue to rally behind a Heimdal Windows client implementation and do the work.  Or people could choose none of the above.  

As Sam Hartman wrote later in this thread, "I think there's an
assumption in my mind and probably the mind of a lot of people here that
without updates to the core libraries that code base will eventually
bit-rot."  The reality is that the MIT Kerberos Consortium permitted the
bit-rot to occur through the development of 1.7.x, 1.8.x and master.
Without keeping the development of the Windows support roughly in sync
with the UNIX platforms the code submitted by non-Windows developers
has resulted in a tree that has significant gaps and cannot build on
Windows.

Worse than the fear of bit-rotting is the fear that is produced
when the entity responsible for producing a core component of the
application infrastructure at your organization refuses to discuss the
future of their product.  At some point those that rely on the product
come to the conclusion that it is dead.  This opinion was recently
voiced by Julien Montmartin on kerberos at mit.edu when he said "I wonder
about the liveness of the kerberos for windows port. Windows has been 64
bits for a few years by now, I'm not sure we can consider
Kerberos to be cross platform (through gss-api) any longer."

Secure Endpoints provided MIT the 64-bit Windows XP/2003 R2 support
before the release of KFW 3.2.2.  The 3.2.2 release announcement
(October 2007) even states that 64-bit Windows builds were enabled by
that release.  MIT chose not to release its own 64-bit installers
leaving it up to Secure Endpoints to distribute 64-bit builds to its
support customers.  The KFW 3.2.3 alpha that was announced in July 2009
is essentially the 3.2.2 release built with the 1.6.4 beta krb5
distribution plus a compilation for the 64-bit platform.

Stephen states that the problem is a lack of resources and commitment
from the community.  I would argue that the actual failure is the lack
of substantive direction from the Consortium on this issue.  In the
Spring of 2008 the Consortium privately discussed with its member
organizations the future of KFW.  At the time the Consortium proposed
halting the release of end-user installation packages and the
distribution of a user interface component.  The Consortium asked for
input on how to package the core libraries as a reusable SDK.  Secure
Endpoints responded to the request by designing a side-by-side assembly
model intended to address many of the shortcomings of the existing KFW
distributions.  The proposal was delivered to the Consortium on 28 July
2008.

  http://www.secure-endpoints.com/kfw/proposal-kfw-assemblies.html

There were no public comments provided in response.  No public statement
of direction was issued.  A plan was never put forward indicating what
the Consortium would like to achieve if only it had the resources.
Instead, the Consortium's public silence on the topic, magnified by each
new UNIX release and public presentation, solidified the perception that
support for the Microsoft Windows platform was in fact dead.

To fill that vacuum Secure Endpoints has continued to pursue the plan
that was outlined in 2007 and 2008 for Network Identity Manager and
Kerberos on Windows.  Network Identity Manager v2 was released last
Winter.  v2.1 will be released in early September.  A full port of
Heimdal to Microsoft Windows including support for side-by-side
assemblies, native Windows crypto and hardware accelerators, public key
authentication, plugable credential cache and replay cache interfaces,
and Windows 7/2008-R2 support will be shipped in the coming weeks.
Asanka Herath presented on this work at the 2010 AFS and Kerberos Best
Practices Workshop.

  http://workshop.openafs.org/afsbpw10/thu_3_2.html

Another motivating factor for this effort is the forthcoming
implementation of the rxgk security class for the Rx RPC protocol family
used by AFS.  rxgk will provide GSS based authentication for AFS
initially supporting Kerberos v5, X.509, and SCRAM mechanisms.  We are
looking forward to implementing future OpenID and SAML mechanisms as
they are developed.  This protocol is dependent upon the GSS-API PRF
(RFCs 4401 and 4402) and a cross-platform public API implementation of
RFC 3961, neither of which are available from existing KFW distributions.

Secure Endpoints has continued to support MIT's Kerberos on Windows
throughout the last three years.  We have produced six incremental
updates to 3.2.2 for our customers including corrections for security
advisories as well as adapting to the changes in Vista, Vista SP1, Win7
and Windows Server Core.  The vast majority of the changes were pushed
back to MIT as patches against 1.6.x in RT.  At some point we stopped
sending updates since the ones we had submitted were not hitting the tree.

We are now approaching the one year anniversary of the Windows 7 RTM
release to large enterprises and development organizations.  Most
of the organizations that Secure Endpoints works with have plans to roll
out Win7 worldwide over the next six months.  These organizations are
right now in the midst of determining what their application stack is
going to look like for the next three to five years.  The Consortium has
lost significant mind share by failing to have a Windows 7 ready release
that meets the criteria discussed back in 2008.  This is a shame because
by permitting KFW development to stagnate, Julien Montmartin's assertion
will be proven correct; the GSS-API will no longer be considered a
viable cross platform API for a large number of organizations.  Its not
that MIT's implementation is better than Heimdal's, its that through its
silence the Consortium forced end user organizations to conclude that
there was no viable implementation on Windows 7 at all.  Decisions for
the next decade were made based on those conclusions.

The saddest part is that one of the most important benefits that the
Consortium could have provided its members was a consistently available
krb5 and gss api.  As more organizations choose to develop for the SSPI
on Windows, there will be a substantial reduction in the cross-platform
availability of those applications, at least until someone decides to
provide an SSPI compatibility API for UNIX.

Secure Endpoints believes that it could bring KFW current in about four
calendar months with a better than full time effort.  However, it would
all be for naught if the Consortium didn't have its own in-house
resource to maintain the code going forward and perform interop testing
with future Microsoft releases while they are in early beta.  We
estimate the cost of development and maintenance would be approximately
$280,000 for the first year with an on-going cost of $120,000 for each
subsequent year.  This is assuming that the efforts Secure Endpoints has
already put into KFW and NIM are accepted as a starting point.

Jeffrey Altman