[OpenAFS] OpenAFS and single DES

[Troy Benjegerdes]

Please have a look at:

https://lists.openafs.org/pipermail/openafs-devel/2010-May/017637.html

It may cost you less in the long term to simply upgrade AFS to use the
'non-standard' rxk5 implementation until someone releases a working rxgk,
or to contract with one of the support vendors to implement rxgk.

I got burned by this when I upgraded one of my kerberos servers, and I
concluded it was better to fork OpenAFS than to wait for a standard to 
appear. The results of my attempt to merge rxk5 to current are at:
https://bitbucket.org/dahozer/tfs

I would appreciate any reports of failures of 
'./configure --enable-rxk5 && make check' on the TFS issue tracker page,
and this will hopefully motivate myself or someone else to fix it.

An excercise you may or may not want to consider, depending on how many
bridges you want to burn, is asking a third-party security audit/red team
to implement a tool to crack the DES Keyfile. This would have the effect
of either lighting a fire under the community to replace DES, or result 
in major institutions dropping AFS completely.


On Fri, Oct 05, 2012 at 02:13:56PM -0400, Jim Green wrote:
> Here at Michigan State, I'm leading a project to upgrade our MIT Kerberos
> system from 1.6.3 to 1.10.x.  One thing we've discovered in our research is,
> in order for AFS to work, we need to turn on support for single DES in our
> Kerberos KDC.
> 
> Short of either OpenAFS being modified not to need single DES (doesn't seem
> likely any time soon), or MSU dropping AFS (it's been suggested, but that's
> complex logistically for us), what are the appropriate steps we should take
> to mitigate the risk?  For example, I've been asked if there is any way to
> limit single-DES to only those transactions that absolutely need it.  Which
> made me realize that I actually do not understand which transactions
> actually need it.
> 
> From reading this post,
> https://lists.openafs.org/pipermail/openafs-info/2010-March/033057.html, it
> seems that OpenAFS client versions 1.4.12 and higher are doing something
> like that on the client side, thereby doing away with the need to set
> "allow_weak_crypto=true" in the Kerberos client, but allowing it for aklog
> only.  Is that right?
> 
> Otherwise, does anyone have any other suggestions to make us feel better or
> worse as far as what the exposure is and what steps we should take to
> mitigate it?  I realize this is a Kerberos question but I'm thinking because
> it relates to AFS some of you may have already put some thought into it as
> well.
> 
> Thanks in advance
> 
> 
> 
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info