KDC session key selection

ghudson@MIT.EDU ghudson at MIT.EDU
Fri Jun 1 09:31:11 EDT 2012


When a KDC serves a ticket in response to an AS or TGS request, it
chooses a session key, which needs to be of an enctype supported by
the Kerberos implementation on the client and server.  (This is
distinct from the reply key, which only needs to be supported by the
client, and from the ticket encryption key, which only needs to be
supported by the server.)

The way we pick a session key right now is to walk the client's
requested enctype list, throw out anything not allowed by the KDC's
permitted_enctypes variable (which is in turn filtered according to
allow_weak_crypto), and then call a hardcoded function which makes the
following assumptions:

1. Nobody supports des-cbc-md5.
2. Everybody supports des-cbc-crc.
3. Otherwise, the server supports an enctype if it has a long-term key
   for that enctype.

Assumption 1 is due to an ancient interop issue (we were supposed to
implement a principal flag for it but never did).  Assumption 2 made
sense is bogus today, since modern Kerberos implementations will
refuse to use DES by default, but it's nevertheless a handy assumption
when an old client (like a Java app using the 1.5 JRE) authenticates
to a service which doesn't have a long-term DES key.  Assumption 3 has
been a sore point for a while, because it forces services to have more
long-term keys than they really need.

We have someone interested in improving this situation.  As I
understand it, the current plan is:

* Add a KDC knob to turn off the assumption that everyone supports
  DES.  (Only relevant if allow_weak_crypto = true, of course.)

* Support a string attribute (as in kadmin setstr) listing the
  supported enctypes for a principal in some form.  If the string
  doesn't exist, we fall back to the current hardcoded logic.

I've tentatively okay'd this.  It's works with existing command-line
tools and is low in code footprint.  It's a little awkward for
integrators who would want to make the decision inside the KDB module,
since it requires them to supply the answer in the form of
KRB5_TL_STRING_ATTRS tl-data (but that's something they will probably
want to support eventually anyway).

Since I know this issue affects a number of deployments, I wanted to
open the design to discussion.  Some other options include:

* Instead of a string attribute, a dedicated tl-data value and new
  kadmin support to modify it (probably a revision of the modprinc
  RPC, like when we added key-salt support to addprinc).  This plan
  provides a more structured admin experience, but may require more
  effort than we have available at the moment.

* A DAL method.  This would really only be useful to integrators who
  are replacing the KDB module.  But it's still pretty low in code
  footprint.

* A KDC pluggable interface for session key support.  This is more
  friendly to large sites who would be using the build-in KDB module
  but have the development resources to write a custom KDC module.
  It's also about as friendly to integrators, since a KDB module could
  also implement the session key support interface and access the DAL
  handle of the server principal entry.  The code footprint of this
  plan would be pretty large, since pluggable interfaces have some
  inherent overhead.


More information about the krbdev mailing list