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
>> 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