On 3 Jun 2012, at 06:18, Jayen Ashar wrote:

> On Sat, Jun 2, 2012 at 11:07 PM, Simon Wilkinson
> <[email protected]> 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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to