[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kerberos
Subject:    Re: Adding higher grade crypto to existing KDC servers while maintaining	weak
From:       William Clark <majorgearhead () gmail ! com>
Date:       2014-10-21 21:43:02
Message-ID: D88805DD-67BB-4862-87BC-1DC1A1F3F8EF () gmail ! com
[Download RAW message or body]

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@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

________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos


[prev in list] [next in list] [prev in thread] [next in thread]