Jeff, On Tue, 23 Oct 2012, Jeffrey Altman wrote:
Those of us with extensive IETF Security Area experience value the benefit of standards review performed via independent implementation. Your File System Inc. completed our implementation of rxgk along with all of the supporting infrastructure more then 18 months ago. All of the required framework modifications to the OpenAFS UNIX source tree were pushed upstream to the 'master' branch. What became a blocker for us contributing the rest of the pieces to OpenAFS was the lack of timely review. As a result Your File System Inc. determined that the only way to bring rxgk and all of the other functionality we developed over three and half years was to create a replacement file system protocol. The other option was to let the staff go find other jobs and walk away from OpenAFS entirely. MIT's commitment of your development time will be the first new significant academic contribution to OpenAFS from a U.S. institution in nearly six years. Your experience with both OpenAFS and Kerberos development makes you the perfect independent reviewer and implementer.
Thank you for these kind words, I am hopeful for the prospects of this project.
In 2008 Your File System Inc. committed to releasing features to OpenAFS from our commercial products one year after initial release. The rationale for that time frame is to ensure that the investments spent on developing the technology can be recouped and used to fund the next round of features and functional improvements. Last week at the European AFS and Kerberos Conference, http://openafs2012.inf.ed.ac.uk/programme, Your File System Inc. announced that version YFS 1.0 would be available for sale to the public in April 2013. Based upon that time scale our rxgk implementation would be contributed to OpenAFS in April 2014. As rxgk is a security protocol, there are significant benefits to having qualified independent review and also an independent implementation to demonstrate that the protocol standard is accurate and sound. However, the AFS3 standardization process does not require it. One choice that needs to be made given the limited resources is whether or not to re-implement the work that YFSi has already performed. As a Gatekeeper, can you speak to what level of functionality and integration work that MIT is committing to? Producing an OpenAFS 2.0 release that includes "rxgk" will require more than just producing an "rxgk" security class. One of the necessary dependencies is removing the last vestiges of LWP from the source tree OR creating a GSS-API stack that uses LWP.
Given that this is a large software project with a long timescale, I do not think I can make useful statements of commitment to particular functionality and integration. MIT's general requirement is a deployable open-source OpenAFS client and server with support for crypto ciphers stronger than single-DES, and I believe this requirement is shared by many other sites. However, this is an overall goal and leaves many things unspecified; certainly we will need more than just an rxgk implementation, but getting one is a good first step and a reasonable initial goal. If the requirements of MIT and the community change along the way, then the goals of my project will adapt to such changing needs.
YFSi has pushed upstream the changes to use pthreaded ubik, the libtool changes to ensure that mixed pthread and lwp libraries do not end up in processes, and many other pieces. There is still substantial work that needs to be finished for OpenAFS. Some pieces YFSi has already completed internally and others that we have avoided because unlike OpenAFS 2.0, YFS 1.0 does not need to support all of the existing tools and interfaces.
The community is grateful to YFSi for the infrastructure work such as this which is frequently unrewarding to the implementor and without significant visible gain at the end of the work. Without infrastructure improvements, many other projects are difficult or impossible.
"rxgk" is a security class but many of the benefits that system administrators associate with the rxgk implementation are far outside the security layer. Cache poisoning protection via use of combined tokens, departmental file services, mandatory security levels, non-Kerberos authentication, etc. are all features that have become associated with "rxgk" because without "rxgk" they cannot be implemented. Can you indicate which functionality MIT is committed to? Or MIT simply interested in providing the minimum necessary to permit GSS Kerberos v5 to be used for authentication and AES-256/SHA-1 to used for wire encryption?
As mentioned above, any "commitment" made at the present time may not be relevant in a year's time. What I am able to do will depend on how much time I have available, what pieces are contributed by the community, and what features are needed by MIT and the community as a whole. We plan to prioritize having a functional implementation that allows the use of GSSAPI with Kerberos 5 as a mechanism and AES256 as the key type, but other functionality will be implemented as time permits. If some organization or individual were to, say, remove LWP dependencies from the source tree in favor of pthreads, then I would have more time to spend on new features such as you list here.
I look forward to seeing how all of this plays out.
I expect that with all the effort being expended, OpenAFS will continue to be a robust and reliable filesystem to be used for many years to come. -Ben _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
