Ticket #529 (new defect) — at Version 10

Opened 12 years ago

Last modified 9 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 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 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.”

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.

Change History

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

  • Milestone set to Fall 2010

comment:4 Changed 12 years ago by andersk

  • Description modified (diff)

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

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

  • Description modified (diff)

Also Brightmail.

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

  • Description modified (diff)

Also Citrix.

Note: See TracTickets for help on using tickets.