You are here

KDC Rekey

Project ID: 
180
Current stage: 
Manager: 
Unit: 
What: 

Description: Migrate our KDCs away from single-DES keys.

Deliverables: Re-keyed KDC.

Why: 

Customer: All

Case statement: For security reasons, we need to move away from using single-DES keys
in our KDCs

When: 

Status:

Timescales:

Priority: High

Time:

How: 

Proposal:

Resources: 1-2 weeks CO time.

Plan:

Evaluation:

  • Investigate encryption types and decide which to use.
  • Look for other organisations who have undertaken a rekey and seek to
    learn from their experiences.

Implementation:

  • Remove both default_tkt_enctypes and default_tgs_enctypes from
    krb5.conf everywhere. DONE
  • On KDC only, add new encryption algorithms to both supported_enctypes
    and kdc_supported_enctypes. There is a complete list of supported
    encryption types in the Admin manual MIT supply with each Kerberos
    release.
  • Take des out of supported_enctypes on the KDC. Don't remove des from
    kdc_supported_enctypes - kerberos component should be checked so that
    it doesn't use same resource for supported and kdc_supported
    attributes.
  • Rekey the TGT, using the --keepold option, to add the new encryption
    types. Services will be rekeyed as they upgrade, users as they change
    their passwords.

Flag day...

  • TGT - remove the old TGT from the database. This is scary, as you
    either have to hand edit the database, or you have to rekey and not
    --keepold, which breaks all of the clients.

Most vital is that throughout this all, it must be possible for DES
keys to still be issued, as the afs service key must remain a single
DES key. This means making sure that whilst the KDC defaults to
created DES keys, it is still prepared to issue and handle them.

Other: 

Dependencies:

Risks: Kerberos underpins much of our infrastructure, so major changes present significant risk if problems arise.

Milestones

Proposed date Achieved date Name Description