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

[Ken Raeburn]

On Jan 29, 2009, at 21:26, Tom Yu wrote:
>   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.

When do you expect these lists to not have DES listed last?

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

However, it does mean any service that indicates it accepts DES  
session keys must also have a DES service key that could be attacked  
(by asking for tickets with the service principal as the client, and  
claiming only to support DES).  That's one reason I've argued before  
that we should decouple these enctype lists, and reevaluate just what  
the actual needs are for various use cases.

Ken