Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009
jhutz at cmu.edu
Fri Jan 30 18:23:39 EST 2009
--On Friday, January 30, 2009 10:17:51 AM -0500 Jeffrey Altman
<jaltman at secure-endpoints.com> wrote:
> 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.
Exactly so. As an operator, one of the largest issues blocking my
elimination of both single-DES and krb4 from our environment is the lack of
tools that allow me to characterize request, not only by enctype and client
principal, but also by other properties such as protocol, service
principal, requested enctypes, client address/hostname, and so on. Such
tools would go a long way toward making our lives easier.
> 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.
That means, among other things, the ability to generate and store new
service keys without taking them into use, the ability to begin issuing
service tickets with a new key while still handling AS requests using the
old client kvno (or vice versa), and a key management protocol and clients
that support these operations.
More information about the krbdev