[OpenAFS] AFS without DES on users' KDCs?

[Matt W. Benjamin]

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" <simonxwilkinson@gmail.com> wrote:

> 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:
> >> 
> >> 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