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

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4E4B1855DB02133FD2480A45
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/23/2012 5:48 PM, Benjamin Kaduk wrote:
> Dear all,
>=20
> 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.
>=20
> This is a long-term project, we expect it to take about a year to run t=
o
> 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.
>=20
> 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 )
>=20
> Hopefully knowing that there is work in progress will be reassuring to
> many who would otherwise worry about the future of OpenAFS.
>=20
> -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




--------------enig4E4B1855DB02133FD2480A45
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQhyCiAAoJENxm1CNJffh41d0IAMjFPFt9WfvSdsmQqWPmAtqb
hACJZLrJIdBdX2uhppKd5miL0nfkIhPj7X3reW4eZrxiDDb+o5eN9qVlJRQv0GZQ
dHuQ5B6XBZhioHOs6428YG6br2OvvP0Kmu6QGyN4tNvfGDiayY9cKUs7a2eoDjlt
ROSXNUERb7u/606j4EPrv3+QdvUFue6RMPPtHIYd9mmELMHDFfVZoUQgFcv29Oss
Rsi23KkUafFxF3bGJKwEAqwyd2ulzWEOn2rIZbP9jbtqHI6v7L5fXJE56+hHw5ZN
L6U79e/WRpITSeW+MeAWejDNgHNCTsEU93D/4TW+dwP56/03HuV2yC5R/pM9LJc=
=sH1m
-----END PGP SIGNATURE-----

--------------enig4E4B1855DB02133FD2480A45--