On Fri, 5 Oct 2012, Booker Bense wrote:
On Fri, Oct 5, 2012 at 11:23 AM, Benjamin Kaduk <[email protected]> wrote:
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).
Are you absolutely sure this is true? I have vague recollections that you
need single DES keys on the krbtgt key to get single DES tickets. But
it's late and I haven't had lunch yet so I may be misremembering.
I am not 100% sure, no. I am actually working on a document with a
procedure for upgrading away from single-DES, and will test it in practice
during the course of that work. (I will send a link when it is finished.)
The main question here is what algorithm the KDC uses to choose the
encryption type for the key in a service ticket: this involves comparing
the supported enctypes sent by the client and the available keys for the
service principal. I don't remember there being an external comparison
involved (if there was, it would probably be the enctypes available in the
highest-kvno krbtgt entry), but there should also be a permitted_enctypes
check against KDC configuration in there. DES must remain permitted as
long as a single service needs keys issued with it, but if all other
service principals do not have DES keys, they cannot have service tickets
issued.
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.
I'm puzzled here as well. Once you remove them offending service keys
from the KDC,
isn't the process more or less done? I know in hiemdal at least that
it's trivial to remove
just a specific enctype from a service principal w/o affecting the
rest of the keys.
Server keytabs and user principals will need rekeying as well, if they
only have single-DES keys in the database. Here at MIT, there are many
kerberized application servers that are not maintained by central IT, so
both those and user principals require user outreach. (I don't have
insight into the situation at Michican State, of course.) At universities
with tenured faculty, I expect it to be politically infeasible to require
a password change more often than once a year. User password changes and
manually rolling new application keytabs is where I am seeing this large
timescale come in.
This is starting from a rather pessimistic mindset; it is possible that
the situation at MSU is better than my model, with most principals already
having both DES and AES keys present. That would simplify things greatly,
as you say.
-Ben
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
