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. 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. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
