DES phase-out and 1.8

[ghudson@mit.edu]

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
(http://k5wiki.kerberos.org/wiki/Projects/Enctype_config_enhancements).

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

  * 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
    new program.

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.
  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007409.html)
  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007417.html)

* (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.
  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007415.html)

* (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.
  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007419.html)

* (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.
  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007417.html)

* (Nico) A krb5.conf setting to determine acceptable enctypes for
  preauth.  I don't think this needs to be different from the current
  default_tkt_enctypes.
  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007419.html)

* (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.
  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007419.html)

* (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.
  (http://mailman.mit.edu/pipermail/krbdev/2009-January/007419.html)