On 9/29/2010 1:38 PM, Steve Simmons wrote: > On Sep 29, 2010, at 12:25 PM, Jeffrey Altman wrote: > >> The last release of Kerberos from MIT for Windows was issued nearly >> three years ago. In an e-mail to krb...@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. . . > >> . . . 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? > > I think your last sentence is a clue. :-) > > 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 Directory and > integration between AD and Kerberos. Based on that: > > IMHO the long-term source of kerberos authentication for windows will come > more and more from Active Directory and ever-closer integration and trust > between AD and Kerberos realms. That's the solution Microsoft would prefer. > Since they're a member of the kerberos consortium they probably swing some > weight on the topic. > > So not only is MIT kfw effectively orphaned, it's deliberately slated for > 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 in 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 != 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=moonshot 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 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? > > Assuming I understand you correctly, you're proposing to remove kfw from 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 when > someone *does* need kfw from this point forward. 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 well. > Conversely, if we direct folks who need kfw to the MIT distribution, it seems > both reasonable and consistent to direct those needing the Heimdal 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 Heimdal > shims is small and will shrink over time. Conversely, those sites which are > actively downloading and running Heimdal on windows have de-facto > demonstrated 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 makes > 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. > > Removing kfw from the standard oAFS git repository also helps reduce the > number of things that are 'part of' oAFS and which users might expect us to > be supporting. IMHO that's a win. In addition, I think it would result in > user complaints about kfw going directly to the Consortium. That's likely to > carry more weight than our second-hand repetition of those complaints. 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 from 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 either add a fixed > kfw as a separate git item in openafs.org or include a patch set that folks > could then apply to MIT kfw. I'm not sure which of those two is preferable, > but we can burn that bridge when we come to it. Similar comments apply to a > future in which the Heimdal shims become moribund. 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
signature.asc
Description: OpenPGP digital signature
