Ticket #529 (closed defect: fixed)
Make Athena ready to transition away from single-DES
Reported by: | andersk | Owned by: | kaduk |
---|---|---|---|
Priority: | normal | Milestone: | The Distant Future |
Component: | -- | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description (last modified by andersk) (diff)
[Not entirely a Debathena bug, but this is the most convenient place to keep track of it.]
As an experiment, I modified my Kerberos principal to have only a triple-DES enctype using kadmin:
kadmin: cpw -e des3-hmac-sha1:normal andersk
This works out fine from a Kerberos client perspective:
- kinit -5,
kinit -45, and krb524init allworks, which allows me to use any Kerberized service as normal, including krb4 Zephyr and krb4 IMAP. krb4 is now effectively disabled - kinit -4 no longer works (kinit(v4): Kerberos principal unknown), which is expected because Kerberos IV can only use a single-DES key to encrypt my TGT.
But that is okay because kinit -45 or krb524init replace this functionality.krb4 is now effectively disabled - aklog and AFS works fine.
However, it exposed some problems with various password-authenticated services:
ca.mit.edu does not allow me to generate a new MIT certificate.FIXED.The PO servers do not allow me to log in over IMAP using a password. (Kerberized IMAP still works.) I receive this error using imtest:FIXED.$ imtest -s -m login andersk.mail.mit.edu … Please enter your password: C: L01 LOGIN andersk {9} S: + go ahead C: <omitted> S: L01 NO Login failed: authentication failure Authentication failed. generic failure
I cannot log in to Webmail, presumably as a consequence of the above: “Login failed.”FIXED.I cannot log in to Touchstone services using a password (though certificate and Kerberos authentication still work): “Error: Please enter a valid username and password. Click help for assistance.”FIXED.Outlook Web Access works fine.I cannot log in to the MITnet VPN (vpn.mit.edu): “Login error.”FIXED.I cannot log in to Brightmail: “Invalid user name or password. Please try again.”FIXED.I cannot log in to Windows after starting the Citrix ICA Client from Citrix MetaFrame XP: “The system could not log you on. Make sure your User name and domain are correct, then type your password again. Letters in passwords must be typed using the correct case.”GONE. The new citrixapps.mit.edu works, however.I cannot log in to the MIT SECURE wireless network:outgoing(-auth) does not accept passwords auth from principals with strong keys, though it does accept GSSAPI auth, much as the PO servers.FIXED.
Given that single-DES is critically weak, is disabled by default in current releases of Kerberos, and will be removed entirely in future releases, we should talk with network and try to get these little problems worked out sooner rather than later.
Solution
In at least one case (ca.mit.edu), the problem was that the server’s /etc/krb5.conf had the line default_tkt_enctypes = des-cbc-crc. This line should be removed. Since we think this misconfigured /etc/krb5.conf has been copied to many MIT servers, that’s probably all we need to do to fix most or all of these problems.
Change History
comment:2 Changed 15 years ago by andersk
In case anyone important is reading this, I should be clear that none of these problems are believed to block a transition to hybrid DES+3DES keys, which would allow the ATHENA realm to continue to function after single-DES is turned off in Kerberos upstream.
comment:4 Changed 15 years ago by andersk
- Description modified (diff)
I found a new problem: I can’t log in to vpn.mit.edu.
comment:5 Changed 15 years ago by andersk
hartmans guesses that the problem with at least some of these services is a krb5.conf with default_tkt_enctypes misconfigured. He also says the KDC logs should be able to identify such misconfigurations if the KDC is running 1.3 or higher (but he thinks it’s running 1.2).
comment:7 Changed 15 years ago by andersk
- Description modified (diff)
jis just told me that ca.mit.edu was fixed, and indeed it works now.
comment:8 Changed 15 years ago by andersk
On Sun, 16 May 2010, Jeffrey I. Schiller wrote:
For the record, ca.mit.edu's copy of Kerberos was just fine. However
/etc/krb5.conf had this line in it:
default_tkt_enctypes = des-cbc-crc
This causes the client to request tickets for des-cbc-crc. Because
Anders didn't have a compatible key, the CA returned the error
observed. The error message is a bit mis-leading. The problem isn't
that the KDC doesn't support the key requested, but that the principal
doesn't have a compatible key (ca.mit.edu is using the Kerberos client
shipped with RHEL 5.3 which is based on krb5 1.6.1).
The fix was to change the line to:
default_tkt_enctypes = des-cbc-crc, des3-hmac-sha1
Removing this line altogether may also work, but I didn't test that
configuration.
-Jeff
comment:9 Changed 15 years ago by andersk
On Sun, 16 May 2010, Anders Kaseorg wrote:
FYI, the Debian documentation for default_tkt_enctypes does recommend
removing the line entirely (it sounds like that would help prevent future
problems of this sort):
# The following encryption type specification will be used by MIT Kerberos
# if uncommented. In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# Thie only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn't know about (such as
# old versions of Sun Java).
# default_tgs_enctypes = des3-hmac-sha1
# default_tkt_enctypes = des3-hmac-sha1
# permitted_enctypes = des3-hmac-sha1
As of krb5 1.8.1, the current default value for all of these lists is
(src/lib/krb5/krb/init_ctx.c, src/lib/crypto/krb/etypes.c)
aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1,
arcfour-hmac, des-cbc-crc, des-cbc-md5, des-cbc-md4
which includes both enctypes that you configured manually; des3-hmac-sha1
is an alias for des3-cbc-sha1.
Debathena has been using the default enctype list with no problems. We
have to enable allow_weak_crypto on newer Kerberos versions for
des-cbc-crc to actually be used, but no manual list of enctypes has been
needed.
Anders
comment:12 Changed 14 years ago by andersk
- Description modified (diff)
Also the MIT SECURE wireless network.
comment:13 follow-up: ↓ 17 Changed 14 years ago by geofft
Anders, how recently have you changed your Kerberos password? There was mail sent to some support list I'm on saying that in order to use MIT SECURE you need to have changed your password since April 2010, so that it gets synced to the (non-Kerberos-aware) RADIUS server. Given that, I have some trouble believing this is key type.
Can you change your password, remove the new 1DES key, and retry some of the recent stuff, especially the things that are likely to be NIST services that sync your password separately and don't use the Athena KDC? Citrix, Brightmail, and the VPN seem likely.
comment:14 Changed 14 years ago by jdreed
- Description modified (diff)
I was able to log in to the MIT SECURE wireless network as "jruser", on MacOS 10.6.4. The initial connection attempt successfully associated but failed to get DHCP. Subsequent connection attempts worked just fine, and I received a valid IP.
kadmin: getprinc jruser Principal: jruser@ATHENA.MIT.EDU Expiration date: [never] Last password change: Wed Sep 15 09:17:15 EDT 2010 Password expiration date: [none] Maximum ticket life: 0 days 21:15:00 Maximum renewable life: 7 days 00:00:00 Last modified: Wed Sep 15 09:17:15 EDT 2010 (jdreed/admin@ATHENA.MIT.EDU) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 5, Triple DES cbc mode with HMAC/sha1, no salt MKey: vno 0 Attributes: Policy: default
comment:15 Changed 14 years ago by jdreed
My understanding at this point is that when Kerberos 1.9 comes out, which should include some patches for the RSA frobs we care about, we will upgrade the KDC to that.
Unofficial conversations suggest that single-DES is unlikely to be removed out from under us while we still need it.
comment:16 Changed 14 years ago by jdreed
Bob believes the Touchstone issue to be a krb5.conf issue and will test the fix on a dev server at some point.
comment:17 in reply to: ↑ 13 Changed 14 years ago by andersk
Replying to geofft:
Can you change your password, remove the new 1DES key, and retry some of the recent stuff, especially the things that are likely to be NIST services that sync your password separately and don't use the Athena KDC? Citrix, Brightmail, and the VPN seem likely.
I changed my password using cpw -e des3-hmac-sha1:normal and retested all the services listed in the description. The only change is that I can log into MIT SECURE now.
comment:18 Changed 14 years ago by rbasch
I tested against a Touchstone dev server with the default_tkt_enctypes line removed from krb5.conf (which seems like the proper fix), and was able to login successfully using a password changed via cpw -e des3-hmac-sha1:normal. I will follow up with NIST.
comment:19 Changed 14 years ago by jdreed
- Priority changed from critical to major
- Milestone changed from IAP 2011 to Natty Alpha
This is not really "critical", now that we have a vague assurance from upstream that DES won't be de-supported out from under us.
comment:20 Changed 14 years ago by rbasch
This should be fixed now on the production Touchstone identity provider (idp.mit.edu), as of yesterday's update, though I have not yet confirmed it.
comment:22 Changed 12 years ago by jdreed
- Milestone changed from Precise Beta to The Distant Future
Now that the cert server does forced password syncs to our other domains, I retried this. There is no change for VPN and Brightmail. I can't get any of the Citrix launchers to even launch, so I can't test that. I suspect we'll WONTFIX the Cyrus stuff, as I expect us to have desupported that long before we get around to punting single DES.
comment:23 Changed 12 years ago by jdreed
- Status changed from new to committed
Re-assigned to our Senior Liaison to the Kerberos Consortium.
comment:24 Changed 12 years ago by jdreed
- Status changed from committed to assigned
- Owner set to kaduk
comment:27 Changed 12 years ago by andersk
- Description modified (diff)
I retested this with an AES-only principal (cpw -e aes256-cts -e aes128-cts). Touchstone, VPN, and Brightmail work! But Webmail, password IMAP, and Citrix still fail. Password IMAP is a blocker for me.
comment:28 Changed 12 years ago by mitchb
- Description modified (diff)
outgoing-auth doesn't accept password auth from principals with strong keys
comment:29 Changed 12 years ago by jdreed
Mark tells me that Cyrus and outgoing will in fact be fixed. Citrixapps.mit.edu (the new Citrix) works fine if you log on to the WIN domain, now that we have password sync'ing. So, uh, I think we're done. "Or we will be on Friday."
comment:30 Changed 12 years ago by jdreed
Citrixapps.mit.edu also works fine with the ATHENA domain with an AES-only principal. I... have no idea why it failed to work 2 hours ago.
comment:31 Changed 12 years ago by mitchb
- Description modified (diff)
krb4 is disabled.
The PO servers are fixed.
Webmail is fixed.
Citrix has a new alternative.
outgoing is still broken.
comment:32 Changed 12 years ago by achernya
Using the smtptest command above, on a sipb0 rekeyed to aes256-cts only, this succeeded, producing:
dr-wily:~> kadmin -p sipb0 Authenticating as principal sipb0 with password. Password for sipb0@ATHENA.MIT.EDU: kadmin: getprinc sipb0 Principal: sipb0@ATHENA.MIT.EDU Expiration date: [never] Last password change: Sun Mar 31 22:13:53 EDT 2013 Password expiration date: [none] Maximum ticket life: 0 days 21:15:00 Maximum renewable life: 7 days 00:00:00 Last modified: Sun Mar 31 22:13:53 EDT 2013 (sipb0@ATHENA.MIT.EDU) Last successful authentication: Sun Mar 31 22:14:00 EDT 2013 Last failed authentication: Fri Mar 29 23:05:34 EDT 2013 Failed password attempts: 0 Number of keys: 1 Key: vno 17, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt MKey: vno 1 Attributes: REQUIRES_PRE_AUTH DISALLOW_SVR Policy: default kadmin: quit dr-wily:~> setenv USERNAME sipb0 dr-wily:~> smtptest -p 465 -m login -s -u $USERNAME -a $USERNAME outgoing.mit.edu verify error:num=19:self signed certificate in certificate chain TLS connection established: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) S: 220 MIT.EDU ESMTP Snedmail (Iroquois for mailer) at Sun, 31 Mar 2013 22:14:17 -0400 C: EHLO example.com S: 250-outgoing.mit.edu Hello DR-WILY.MIT.EDU [18.181.0.233], pleased to meet you S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-8BITMIME S: 250-SIZE 41943040 S: 250-ETRN S: 250-AUTH GSSAPI LOGIN S: 250-DELIVERBY S: 250 HELP C: AUTH LOGIN S: 334 VXNlcm5hbWU6 Please enter your password: C: c2lwYjA= S: 334 UGFzc3dvcmQ6 C: [REDACTED] S: 235 2.0.0 OK Authenticated Authenticated. Security strength factor: 256 C: QUIT 221 2.0.0 outgoing.mit.edu closing connection Connection closed. dr-wily:~>
comment:33 Changed 12 years ago by adehnert
- Description modified (diff)
As of 3/31/13, outgoing.mit.edu seems to work with sipb0 (which is now aes256-cts-hmac-sha1-96).
comment:34 Changed 12 years ago by andersk
- Status changed from assigned to closed
- Resolution set to fixed
- Description modified (diff)
Reverified using my own principal. Yay.
debathena / krb5 / ghudson 16:07 (Steel and circuits will make me whole)
debathena / krb5 / andersk 16:20 (Anders Kaseorg)