Ticket #529 (new defect) — at Version 14

Opened 14 years ago

Last modified 11 years ago

Make Athena ready to transition away from single-DES

Reported by: andersk Owned by:
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description (last modified by jdreed) (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 work, which allows me to use any Kerberized service as normal, including krb4 Zephyr and krb4 IMAP.
  • 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.
  • 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:
    $ 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.”
  • 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.”
  •  Outlook Web Access works fine.
  • I cannot log in to the  MITnet VPN (vpn.mit.edu): “Login error.”
  • I cannot log in to  Brightmail: “Invalid user name or password. Please try again.”
  • 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.”
  • I cannot log in to the MIT SECURE wireless network:

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 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
Note: See TracTickets for help on using tickets.