Tangent, was: Review of <<Disable DES1>>

Henry B. Hotz hotz at jpl.nasa.gov
Mon Feb 2 14:04:36 EST 2009

On Jan 30, 2009, at 9:11 AM, krbdev-request at mit.edu wrote:

>> In addition, improvements in support for key rollover must be  
>> provided.
>> If we are going to force a massive rollover of keys it should be
>> combined with support that permits key rollover to be performed on a
>> regular basis.
> Such as with a daemon or with cronjobs?  But this sounds to me like a
> problem for vendors and integrators, not one for MIT, though MIT can
> certainly help.

Do you mean key rollover for:

1) master key
2) krbtgt key
3) service key


Each one of those cases can be handled "transparently" with the right  
support.  All are desirable at one time or another.  Each must be done  
differently.  IIUC MIT can do 2 and 3 currently (and Heimdal 1 and 3)  
and you are adding support for 1).

Assuming it's 3) that's being discussed, and the issue is getting  
service principals with DES1 keys, or updating them to remove DES1  
keys, then it's going to be necessary for the distribution to support  
DES1 keys for AFS/NFS for several years as exceptions.  I would hope  
that the "Crappy Java Applications" will have independent pressure to  
move from 1.4.2 to 1.5+ and won't be as big a deal.  I think most  
Telnet uses can be replaced with ssh (preferably with Simon's  
patches).  A no-DES1 compile option is OK but shouldn't be default  
until there are viable AFS/NFS implementations with significant  

+1 to all the comments about configuring enctypes on a per-principal  
basis.  Likewise for a global disable-des option, as long as it can  
allow specific exceptions.
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu

More information about the krbdev mailing list