Ticket #1308 (closed enhancement: fixed)

Opened 8 years ago

Last modified 5 years ago

Don't set allow_weak_crypto

Reported by: adehnert Owned by:
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version: debathena-kerberos-config 1.20
Upstream bug:

Description (last modified by adehnert) (diff)

Once sufficient progress has been made on Debathena #529 to let users get away without using 1DES, Debathena should stop setting allow_weak_crypto in /etc/krb5.conf.

Status wiki

We believe that:

  • On client machines, we can unset allow_weak_crypto once the users on the machine have strong keys and the servers they communicate have strong keys.
  • On application servers, we can unset allow_weak_crypto once the users connecting have a vaguely recent kerberos and the server has a strong key. (If it accepts passwords, the users also need to have a strong key.)
  • On the KDC, we don't care because it doesn't run Debathena.

Key rolling status:

  • FIXED: We believe that the cert update process will roll keys, so all (active-ish) users should now have updated keys.
  • FIXED: AFS servers now use a hack to use AES keys, plus mostly don't count because of krb5_allow_weak_crypto.html (see comment:3).
  • FIXED: Except for AFS (above), Server Operations' keys have all be updated (see comment:4).
  • FIXED: The PO servers (IMAP) have new keys
  • FIXED: SIPB services are generally rolled (contacting the maintainers is probably reasonable for anything that isn't, but we think that's done)
  • Presumably user outreach is required to get other application servers to roll their keys.

Change History

comment:1 Changed 8 years ago by adehnert

We believe that:

  • On client machines, we can unset allow_weak_crypto once the users on the machine have strong keys and the servers they communicate have strong keys.
  • On application servers, we can unset allow_weak_crypto once the users connecting have a vaguely recent kerberos and the server has a strong key. (If it accepts passwords, the users also need to have a strong key.)
  • On the KDC, we don't care because it doesn't run Debathena.

We believe that the cert update process will roll keys, so all (active-ish) users should have updated keys by ~September even without any additional work. Presumably user outreach is required to get the application servers to roll their keys.

We also should talk with Mark or Garry or somebody similarly relevant about doing this, migration plans, etc. before disabling allow_weak_crypto.

comment:2 follow-up: ↓ 3 Changed 8 years ago by ghudson

Perhaps this is implicit, but AFS is going to present a roadblock to "the servers they communicate [with] having strong keys" for a while yet.

comment:3 in reply to: ↑ 2 Changed 8 years ago by adehnert

Replying to ghudson:

Perhaps this is implicit, but AFS is going to present a roadblock to "the servers they communicate [with] having strong keys" for a while yet.

AFS doesn't count, because aklog already uses  http://web.mit.edu/kerberos/krb5-latest/doc/appdev/refs/api/krb5_allow_weak_crypto.html.

comment:4 Changed 8 years ago by jweiss

I will note that Server Operations has updated all of its service keys with the exception of AFS keys (and by update, I mean explicitly making sure the current version of the key does not have a 1DES enctype.) I believe SIPB has effectively done this too, with the possible exception of host keytabs on workstation class machines. Looking at my credentials cache at the moment, besides AFS, the thing I see that still has a 1DES key is the old IMAP infrastructure (tho there may be other services that I don't use that are still in this state.) There are undoubtedly random users out there with host keytabs for their workstations that will also need addressing.

comment:5 Changed 8 years ago by adehnert

  • Description modified (diff)

comment:6 Changed 8 years ago by adehnert

  • Description modified (diff)

comment:7 Changed 8 years ago by adehnert

  • Description modified (diff)

comment:8 Changed 7 years ago by adehnert

  • Description modified (diff)

I think everything may now be ready for unsetting allow_weak_crypto. Can we do so now?

comment:9 Changed 6 years ago by kaduk

  • Status changed from new to review

comment:10 Changed 6 years ago by kaduk

  • Status changed from review to committed

committed  44eb26c20afbdde30fca7718948a8abc608d0824 (Unset allow_weak_crypto) to master

comment:11 Changed 6 years ago by bbaren

Hurrah!

comment:12 Changed 6 years ago by kaduk

  • Status changed from committed to development

comment:13 Changed 5 years ago by andersk

  • Status changed from development to proposed
  • Fixed in version set to debathena-kerberos-config 1.20

comment:14 Changed 5 years ago by andersk

  • Status changed from proposed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.