Adding higher grade crypto to existing KDC servers while maintaining weak

[Benjamin Kaduk]

Hi William,

On Sun, 19 Oct 2014, William Clark wrote:

> I know this seems like an idiotic thing, but here is the scenario.  I
> have a multi KDC setup that has been the backbone of Kerberos for a
> large organization.  Traditionally we have had to keep week crypto
> around because of some legacy tools that cannot be rewritten at this
> time.
>
> I want to prepare for the future, and also allow OS X Yosemite (10.10)
> users to be able to kinit right now.  In the case of the Yosemite users,
> they cannot because Apple locked down the ability to use weak crypto in
> this release regardless of if one has allow_weak_crypto = TRUE in their
> krb5.conf or edu.it.Kerberos.  So my thought is to find the minimum I
> need to do to start allowing clients to auth via stronger crypto like
> AES.  I know I will have to rekey the main service principals, but what
> I am fuzzy on is if I would need to rekey every principal, which would
> cause quite the headache.

We created the document
http://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html
to cover the steps needed to convert a realm using only single-DES into
one using modern crypto (e.g., AES).

> Has anyone gone through this and can give me some guidance on what in
> addition to the service principal rekeys I would need to do to just
> allow clients that can no longer communicate using weak crypto.  My idea
> is also to issue all new principals going forward with the additional
> key.  The part that I need to suss out is if I need to rekey 100,000+
> principals at this time and if I did how I would do this with the least
> downtime.  I know in the future when no weak crypto is needed I will
> probably have a parallel system setup and move people over to it using
> my L3DSR VIP setup.  But this will be a major undertaking just to issue
> the new keytabs alone.

Clients need to have new keys in order for their interaction with the KDC
to be protected by strong crypto, but clients running new software will
tell the KDC that they support stronger enctypes.  Service tickets are
encrypted in a long-term key for the service taken from the KDC database,
so in order for the tickets to be encrypted in a strong key, the services'
keytabs must be updated.  Session keys are given to the client by the KDC
and included in the contents of the (encrypted) service ticket.  The
session key is used to secure the communications between the client and
the application server; what enctype is used for the session key is
controlled by both the list of supported enctypes sent by the client to
the KDC and the enctypes in the service's KDC database entry (the
strongest one supported by both is used).

I don't know what the distribution of applications that do not support
strong crypto is, but most likely there will be a lot of work involved in
getting strong crypto for those entities which support it, if you are
starting from a DES-only environment.

-Ben Kaduk