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

[Tom Yu]

Simon Wilkinson <simon at sxw.org.uk> writes:

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

Several people have made remarks along these lines.  There is also
risk associated with introducing too many new knobs, and I am trying
to find a balance.

It seems that one reasonable starting point is to cause kadmind to
stop generating long-term single-DES keys.  This could cause problems
for users who change their passwords after such a configuration is set
up but who still use client software that does not support enctypes
other than single DES.  Perhaps modifying kadmind to distinguish user
principals from service principals would be a good idea.

Another idea, which I think Zhanna came up with recently, is to alter
the algorithm for selection of session keys.  Currently, the KDC takes
the intersection of the enctype list provided by the client in the
request and the enctypes supported by the service, in the order
presented in the request.  If both the client and the service support
enctypes other than single DES, those enctypes should have priority
over single-DES enctypes regardless of what order they actually appear
in the request or KDB entry.  One way to accomplish this is to reorder
the enctype lists to place the single-DES enctypes last.  For service
principals, this can be done on a one-time basis with a specialized
program.  For enctypes listed in client requests, this needs to be
done for each incoming request.

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

We already have this capability, to some degree.  The list of keys in
the KDB entry for a service principal (approximately) indicate the
acceptable session key enctypes for that principal.  Suggestions for
interfaces for making this more manageable are welcome.