On Fri, 5 Oct 2012, 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
This is blocking on standardization work, which is inherently slow. Ours
is probably slower than the inherent slowness, though.
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?
That's correct.
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.
You can limit your exposure by having the afs/cell@realm principal be the
only principal in the database with a single DES key. The
default_enctypes do not need to include single-DES, and you can safely
make both user principals and krbtgt/realm have no weak keys, the weak
crypto will only be used to obtain an afs service ticket (and the
corresponding token).
I would expect that completely removing single DES (with the exception of
AFS) would require a year or more to transition fully, in a large
deployment.
-Ben Kaduk
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
