Ticket #1308 (closed enhancement: fixed)
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:2 follow-up: ↓ 3 Changed 12 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 12 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 12 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:8 Changed 11 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:10 Changed 10 years ago by kaduk
- Status changed from review to committed
committed 44eb26c20afbdde30fca7718948a8abc608d0824 (Unset allow_weak_crypto) to master
comment:11 Changed 10 years ago by bbaren
Hurrah!
comment:13 Changed 8 years ago by andersk
- Status changed from development to proposed
- Fixed in version set to debathena-kerberos-config 1.20
comment:14 Changed 8 years ago by andersk
- Status changed from proposed to closed
- Resolution set to fixed
We believe that:
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.