[OpenAFS] OpenAFS and single DES

[Jim Green]

Thanks for the responses, this is very helpful. One question:  are you
saying that if our existing user principals have both AES and DES encrypted
keys that it is possible to remove the DES keys without having to force all
our users to change their passwords (e.g. with kdb_util dump/load)?  It
seems to me I've read conflicting opinions on that.  

It does make sense to me that if a principal had only single-DES keys then
the only way to get stronger ones would be to trigger their creation via
changing password, etc.

When MSU rolled out Kerberos 5 in 2005 we did force everyone to change their
passwords and my understanding is they all got triple-DES and AES keys in
addition to DES at that time and going forward.
 

> 
> On Fri, 5 Oct 2012, Booker Bense wrote:
> 
> > On Fri, Oct 5, 2012 at 11:23 AM, Benjamin Kaduk <kaduk@mit.edu>
> 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
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info