Review of http://k5wiki.kerberos.org/wiki/Projects/Disable_DES ending February 13, 2009
kenh at cmf.nrl.navy.mil
Fri Jan 30 14:07:16 EST 2009
>> We were required to turn off 1DES a long time ago, and any exceptions
>> we had to document.
>and how long did it take you to get to that point?
I think ... from start of "remove 1DES" to "1DES is removed" was
approximately one year. But that was a while ago, and we had severe
management pressure for that.
>I will point out that your site has been running with the 3DES Telnet
>patch now for years. This is not true for the MIT Kerberos unsupported
Well, yeah ... but how many people like us are crazy enough to use Kerberos
>I'm not arguing that it cannot be or should not be done. 1DES must be
>removed. I'm only arguing that it must be done in a manner that permits
>organizations to phase in the transitions. You can't simply remove the
>ability for end users to obtain 1DES service tickets. Many orgs simply
>do not have a list that says here are all of the clients and all of the
>services and what enctypes are required or compatible. Instead, it is a
>lot safer to define a policy and apply it to a subset of the principals
>that are believed to be safe to restrict a little at a time.
If you run MIT Kerberos, it's actually not hard to at least get a
handle on the problem. The KDC logs include which enctypes
applications indicate that they support in their requests and the
enctypes of the tickets and session keys that are issued. Want to know
how many of your clients only support single-DES? I do (sadly, the
number is not zero, again due to a crappy Java application). Last time
I checked, Heimdal would require modifications to log this information
(but I'm sure the modifications would be straightforward). At least
getting a handle on the size of the problem would build a useful
foundation for how we should proceed.
More information about the krbdev