[OpenAFS] OpenAFS and single DES

[Benjamin Kaduk]

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