Adding higher grade crypto to existing KDC servers while maintaining weak

[William Clark]

Want to thank you for your pointers.  I went through a dry run today and found that I needed to rekey 4 of my service principals, update KDC's to issue all new principals with old and new encryption types, and have my users who want to use these higher enctypes right away, change their passwords to get the new keys added to their principals.

Along with a change to their krb5.conf or edu.it.Kerberos to support the encryption types, this was this was enough to support OS X Yosemite.

William Clark



> On Oct 19, 2014, at 6:50 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
> 
> 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