Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009
Nicolas.Williams at sun.com
Fri Jan 30 11:57:08 EST 2009
On Fri, Jan 30, 2009 at 10:17:51AM -0500, Jeffrey Altman wrote:
> For the rxkad security class used by AFS both the service principal long
> term key and the session keys must be 1DES.
> For telnet deployments that do not support CAST or 3DES ENCRYPT options,
> the session key must be 1DES although the long term key can be anything.
These uses of 1DES can be controlled in the KDB.
If the KDC would issue a Ticket encrypted in a 1DES key or with a 1DES
session key, then the client should be happy to use it. Yes, the client
could object, but that's not as practical as leaving it to realm policy;
as long as the client doesn't ask for 1DES session keys except when an
application (like TELNET) requires it, then we should be happy.
> I forget if there is a restriction on the session key enctype for the rcmds.
IIRC there is none.
> From a realm management perspective it is not going to be possible to
> simply turn off 1DES. Any product that does is going to cause serious
> enough headaches for administrators that the product will not be
> deployed. There are simply too many client and service applications
> deployed in the existing infrastructure that require 1DES. What is
> required is a set to tools that permit enctype policies to be created
> and assigned to principals coupled with tools that can be used to
> examine the KDC logs to determine which client principals are requesting
> which enctypes. That information combined with the policies can be used
> to migrate the realm in phases.
I agree, but the truly hard part is dealing with AS-REQ, to prevent a
client from using a weak enctype during pre-auth. The rest can be
> 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
More information about the krbdev