[OpenAFS] Re: [OpenAFS-devel] rxgk development has been funded

[Benjamin Kaduk]

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