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

[Jeffrey Altman]

Nicolas Williams wrote:
> On Thu, Jan 29, 2009 at 06:38:52PM +0000, Simon Wilkinson wrote:
>> I'd like to see some consideration of making this switch more  
>> granular. Many of us are in a situation where we'd love to get rid of  
>> single DES, but we have some protocols (AFS in particular, but I'm  
>> sure there are places with other locally developed protocols which  
>> have similar problems) which rely upon single DES being available.
>>
>> Would it be possible to consider providing a configurable white list,  
>> where DES can be defined as acceptable for certain service principals?  
>> This would provide an easy mechanism for sites to disable single DES  
>> in general, but still have it for a certain limited set of uses.
> 
> This is for service ticket encryption keys or service ticket session
> keys, right?  If so I suggest that this be controlled through metadata
> attached to the service principals in the KDB.

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.

I forget if there is a restriction on the session key enctype for the rcmds.

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

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.

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090130/5bded7e2/attachment.bin