[OpenAFS] AFS without DES on users' KDCs?

[Simon Wilkinson]

On 2 Jun 2012, at 01:47, Jayen Ashar wrote:

> Would setting up our own realm for the AFS server work?  Could all
> users would be authenticated cross-realm?  (We are not concerned with
> cross-realm attacks at the moment.)  Would any changes be needed to
> the users' KDCs?

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.

> We saw rxgk on the OpenAFS roadmap.  Would rxgk solve our problem?

Yes. rxgk improves OpenAFS's security in a number ways. One of these is =
that it provides support for any encryption type which is supported by =
your Kerberos library and KDC - so you can use rxgk with, say, AES =
encryption types.

> What is the status of rxgk?  Could we use it in production?  Where can
> we get the source?

The status of rxgk is somewhat complicated. Your File System Inc =
commissioned me to research, specify, and implement rxgk around 3 years =
ago. As part of this work, I produced two internet drafts defining the =
rxgk protocol, and an initial implementation - this work was completed =
about a year ago.=20

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.

> What patches need to be made to support encryptions other than DES?
> Right now, we are stuck with asetkey not handling AES-encrypted
> keytabs, but other than patching asetkey, would we have to patch aklog
> or anything else?  If we built off of OpenAFS 1.7, could we use the
> AES code in external/heimdal/hcrypto?  Might patches be accepted
> upstream?

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.

Cheers,

Simon.