Thanks for all the details. We'll try setting up our own realm and see how we go. If there's some small way I can help with rxgk, please let me know.
Thanks, Jayen On Mon, Jun 4, 2012 at 3:44 AM, Matt W. Benjamin <m...@linuxbox.com> wrote: > Hi, > > Marcus and I consider rxk5 to be a closed effort. We did make rxk5 partly as > a challenge to the OpenAFS participants to adopt a candidate solution > quickly, since the transport security problem was (and is) pressing. It > should have been seriously considered for integration in 2006-7, since we > were basically done by then. We even had Windows integration. It was not > "unreviewable." It is, however, surely superceded by rxgk. > > It sounds like rxgk might be suitable for experimentation, in private cells > and similar scenarios. I wasn't aware that rxgk isn't yet available in a > form folks could (or should) use, but from what I can tell, that's only for > casual reasons which could be overcome with some private discussion and > modest time commitment from a couple of people. Perhaps that's the case, > anyway. > > Regards, > > Matt > > ----- "Simon Wilkinson" <simonxwilkin...@gmail.com> wrote: > >> On 3 Jun 2012, at 06:18, Jayen Ashar wrote: >> >> > 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? >> >> 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. >> >> 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 >> >> _______________________________________________ >> OpenAFS-info mailing list >> OpenAFS-info@openafs.org >> https://lists.openafs.org/mailman/listinfo/openafs-info > > -- > Matt Benjamin > The Linux Box > 206 South Fifth Ave. Suite 150 > Ann Arbor, MI 48104 > > http://linuxbox.com > > tel. 734-761-4689 > fax. 734-769-8938 > cel. 734-216-5309 _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info