On Sat, Jun 2, 2012 at 11:07 PM, Simon Wilkinson <simonxwilkin...@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 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.
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 while, > and I haven't had enough time to move them forwards. Until the drafts reach > consensus there's no way that OpenAFS can incorporate the rxgk code. When the > code is contributed to OpenAFS, it will be on top of the current 'master' > 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 the > 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 directly > 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 > challenge. Adding multiple encryption algorithm support to rxkad has been > discussed a number of times in the past, but the complexity of the problem, > and the lack of security of the resulting solution, is what led to the > complete security class redesign in rxgk. The critical thing to consider is > how to ensure compatibility, both with legacy clients and legacy cells. This > means that in addition to all of the work done to add the new encryption > algorithms, 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 _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
