[OpenAFS] AFS without DES on users' KDCs?

[Jayen Ashar]

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 <matt@linuxbox.com> wrote:
> Hi,
>
> Marcus and I consider rxk5 to be a closed effort. =A0We did make rxk5 par=
tly as a challenge to the OpenAFS participants to adopt a candidate solutio=
n quickly, since the transport security problem was (and is) pressing. =A0I=
t should have been seriously considered for integration in 2006-7, since we=
 were basically done by then. =A0We even had Windows integration. =A0It was=
 not "unreviewable." =A0It is, however, surely superceded by rxgk.
>
> It sounds like rxgk might be suitable for experimentation, in private cel=
ls and similar scenarios. =A0I wasn't aware that rxgk isn't yet available i=
n 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 an=
d modest time commitment from a couple of people. =A0Perhaps that's the cas=
e, 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? =A0Or is it intertwined with proprietary YFS
>> > code? =A0Any 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. =A0I found code that
>> > patches it against OpenAFS 1.5. =A0Would building off of rxk5 be an
>> > avenue we want to explore? =A0Is 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 =A048104
>
> http://linuxbox.com
>
> tel. 734-761-4689
> fax. 734-769-8938
> cel. 734-216-5309