DES phase-out and 1.8
ghudson at mit.edu
Sun Jan 3 17:27:55 EST 2010
Unfortunately, we haven't revisited the DES phase-out issue since the
1.7 discussion, and we are once again under the pressure of a release
schedule. 1.8 will have only a two-month testing period, and is
expected to branch as early as tomorrow.
What has happened so far: in 1.7, we removed single DES in
supported_enctypes, meaning new principals aren't created with single
DES keys by default. For 1.8, we implemented a more flexible syntax
for enctype configuration variables
What I'd like to do for 1.8:
* Remove single DES from default_tkt_enctypes. This is to prevent
the attack (mentioned by Nico and others in past conversations)
where you (1) spoof an AS reply to say "preauth is required, and
only single DES is allowed" to get the client to encrypt a
timestamp in the single-DES string-to-key of the password; (2)
conduct an offline brute-force search against that plaintext to
find the DES key; and (3) use that key to spoof KDC replies to
future AS requests from that principal.
This change may be disruptive to sites which still need to use DES
in AS exchanges (client or service principals with only DES keys,
or client code which can only do DES); they may need to add DES
back to default_tkt_enctypes. Protecting more modern deployments
* Add code to restrict the AS reply enctype so that it must be one
of the requested etypes. Right now we don't place any
restrictions on the enctype of AS replies.
* Continue to allow single DES for service keys
(default_tgs_enctypes) and session keys (permitted_enctypes). The
enctypes selected by TGS and AP exchanges are protected, so you
will only get single DES service or session keys if the actual KDC
or application server wants to do so. Migration away from DES for
these use cases is better accomplished via the KDC and servers,
rather than the client defaults.
* Time permitting, write documentation and/or non-invasive tools to
aid migration away from single DES. An example of a non-invasive
tool would be a log and/or database analyzer which installs as a
I've reviewed the list conversation from a year ago. Here are a
summary of the suggestions from that thread and how they fit in:
* (Simon) "A configurable whitelist for which service principals to
allow DES for"; probably similar to (Jeff) "tools to permit enctype
policies to be created and assigned to principals." I'm not
entirely sure what this means; my best guess is that the request is
for supported_enctypes to become dependent on the principal name.
* (Ken R) Decoupling a service's session key enctypes from its
long-term service key enctypes. Potentially useful, particularly
for AFS (it's much easier to get AFS to work with non-DES service
keys than session keys), but it's too late to do this for 1.8.
* (Nico) Adding realm policy information which clients can retrieve at
realm-join time to determine what enctypes to allow for AS requests.
Not really possible for 1.8 at this point, and I think a simpler
approach is acceptable.
* (Jeff) Tools to examine KDC logs to determine who is requesting what
enctypes. This is a possibility for 1.8 depending on how busy the
next month is.
* (Nico) A krb5.conf setting to determine acceptable enctypes for
preauth. I don't think this needs to be different from the current
* (Nico) A kadmin interface determining enctypes allowed for service
principals. I don't entirely understand this one, especially
because I don't think our KDC strongly differentiates between client
and service principals.
* (Nico) A build-time setting determining the default for
default_tkt_enctypes. (Nico phrased this in terms of a new option
determining what enctypes are permissible for preauth, but I don't
think that needs to be different from default_tkt_enctypes.) This
should be doable as part of the plan.
More information about the krbdev