On 10/23/2012 5:48 PM, Benjamin Kaduk wrote: > Dear all, > > I wanted to give a heads-up that MIT has funded me to work on > implementing rxgk for OpenAFS. MIT is committed to AFS as part of our > basic infrastructure, and we recognize that the current DES-based > security class in OpenAFS is aging rapidly. Implementing the new > GSSAPI-based rxgk will help us meet our own needs, and also help the > community at large to modernize their own deployments. > > This is a long-term project, we expect it to take about a year to run to > completion. There won't be much to look at or try out in the first > months, but we will call for testers when we're ready for them. > > The work will of course need to progress through consensus of the > afs3-standardization group and my first steps will be reviving > discussion there. ( > http://lists.openafs.org/mailman/listinfo/afs3-standardization ) > > Hopefully knowing that there is work in progress will be reassuring to > many who would otherwise worry about the future of OpenAFS. > > -Ben Kaduk
Ben: 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. 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. 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. "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? I look forward to seeing how all of this plays out. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
