Ticket #529 (closed defect: fixed)

Opened 14 years ago

Last modified 11 years ago

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 all works, 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:1 Changed 14 years ago by andersk

  • Description modified (diff)

debathena / krb5 / ghudson 16:07 (Steel and circuits will make me whole)

Mark says that Touchstone changed the code base it validates
passwords with, which may make the andersk triple DES experiment
work. (#529)

debathena / krb5 / andersk 16:20 (Anders Kaseorg)

Nope. Now it says

“Error: Please enter a valid username and password.

Click help for assistance.”

comment:2 Changed 14 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:3 Changed 14 years ago by jdreed

  • Milestone set to Fall 2010

comment:4 Changed 14 years ago by andersk

  • Description modified (diff)

I found a new problem: I can’t log in to vpn.mit.edu.

comment:5 Changed 14 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:6 Changed 14 years ago by andersk

  • Description modified (diff)

Also Brightmail.

comment:7 Changed 14 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 14 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 14 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:10 Changed 14 years ago by andersk

  • Description modified (diff)

Also Citrix.

comment:11 Changed 14 years ago by jdreed

  • Priority changed from major to critical

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 13 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 13 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 13 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:21 Changed 13 years ago by jdreed

  • Milestone changed from Natty Alpha to Fall 2011

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:25 Changed 12 years ago by jdreed

  • Status changed from assigned to committed

See also #489

comment:26 Changed 12 years ago by jdreed

  • Status changed from committed to assigned

comment:27 Changed 11 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 11 years ago by mitchb

  • Description modified (diff)

outgoing-auth doesn't accept password auth from principals with strong keys

comment:29 Changed 11 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 11 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 11 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 11 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 11 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 11 years ago by andersk

  • Status changed from assigned to closed
  • Resolution set to fixed
  • Description modified (diff)

Reverified using my own principal. Yay.

Note: See TracTickets for help on using tickets.