[OpenAFS] AFS without DES on users' KDCs?

Simon Wilkinson simonxwilkinson@gmail.com
Sun, 3 Jun 2012 14:23:02 +0100


On 3 Jun 2012, at 06:18, Jayen Ashar wrote:

> On Sat, Jun 2, 2012 at 11:07 PM, Simon Wilkinson
> <simonxwilkinson@gmail.com> wrote:
>> On 2 Jun 2012, at 01:47, Jayen Ashar wrote:
>>=20
>> Yes. This should work, provided you can set up a cross realm trust =
between the active directory realm, and the one in which your AFS =
service lives. The only change necessary to the user's KDCs would be to =
enable this cross realm trust.
>=20
> Would this work as a one-way trust?

I think it should, but I've never tried it, and so can't give you a =
definitive answer.

> Is this available on github, or as a patch to some commit in the
> OpenAFS 'master' branch?  Or is it intertwined with proprietary YFS
> code?  Any copyright/licensing issues that prevent it from being
> publicly available to non-customers?

We made an earlier version of the code available for review back in =
2010, to accompany a talk and demonstration I gave at the European AFS =
Conference in Pilsen. As far as I'm aware, nobody reviewed that code - =
we certainly received no feedback. Since that code drop, there have been =
some modifications to the protocol such that that code won't =
interoperate with a current version of the draft.

This is a big problem - security indexes (the code points that identify =
different security classes such as rxkad, rxk5 and rxgk) are in =
relatively short supply. We don't really want people deploying =
non-standardised versions of rxgk for the AFS-3 services in production, =
as it will cause all manner of problems when OpenAFS is finally able to =
release code. I had that problem several years back with the GSSAPI SSH =
internet draft, and my implementation for OpenSSH. There are still =
distribution carrying workaround patches for that particular mess.

The first hurdle here is getting rxgk through standardisation. This =
means that we need to find a way of avoiding the current cycle of =
publication, then months of inactivity, followed by a call for final =
comments, followed by months more inactivity, followed by comments that =
cause the whole process to restart.

> I discovered rxk5 after I sent that last email.  I found code that
> patches it against OpenAFS 1.5.  Would building off of rxk5 be an
> avenue we want to explore?  Is there some inherent problem with it
> that led to the redesign in rxgk?

rxgk was the original solution to getting better encryption in AFS - it =
was originally designed in 2004. But nobody had the effort available to =
complete that design, or to produce an implementation. As a response to =
this, Marcus Watts produced rxk5. rxk5 is a purely Kerberos v5 security =
class that aims to just replace the current security layer. It doesn't =
have many of the more advanced security features of rxgk, but was =
designed to fill the gap before that was available. Whilst there were =
some more structural concerns, such as rxk5's use of a different =
encryption key for every packet (approx 1k) transmitted, the main reason =
that rxk5 has never advanced is that it was only ever made available as =
a monolithic patch set against specific versions of OpenAFS. This meant =
that review and integration was pretty much impossible.=20

The last rxk5 patch set is against a sufficiently old version of OpenAFS =
that forward porting it to master, and splitting it into small enough =
changes that it can be reviewed, is likely to be a major undertaking.

Cheers,

Simon