[OpenAFS] AFS without DES on users' KDCs?

[Jayen Ashar]

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:
>
> Yes. This should work, provided you can set up a cross realm trust betwee=
n 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.

Would this work as a one-way trust?  The AFS service realm trusting
the users' AD Domain?  I doubt the AD admins would allow a two-way
trust.

> The drafts have been stalled in the AFS standardisation process for a whi=
le, and I haven't had enough time to move them forwards. Until the drafts r=
each consensus there's no way that OpenAFS can incorporate the rxgk code. W=
hen the code is contributed to OpenAFS, it will be on top of the current 'm=
aster' branch - rxgk isn't going to be easily available for the 1.4, or 1.6=
 branches, due to the number of changes that are required to the rest of th=
e code to fit in a new encryption library.
>
> In the meantime, YFS have a production ready implementation of rxgk which=
 they are making available to customers - I'd suggest contacting YFS direct=
ly if this interests you.

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?

> Supporting non-DES encryption types without doing rxgk is a pretty big ch=
allenge. Adding multiple encryption algorithm support to rxkad has been dis=
cussed a number of times in the past, but the complexity of the problem, an=
d the lack of security of the resulting solution, is what led to the comple=
te security class redesign in rxgk. The critical thing to consider is how t=
o ensure compatibility, both with legacy clients and legacy cells. This mea=
ns that in addition to all of the work done to add the new encryption algor=
ithms, you also need to support robust algorithm negotiation.

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?

Thanks,
Jayen