Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009

[Nicolas Williams]

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
realm-mediated policy.

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

Nico
--