Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8274207

Remove weak etypes from default krb5 etype list

    XMLWordPrintable

    Details

    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      Hide
      Modern Kerberos servers (Windows 2008 and later, MIT krb5 since 2004) already use AES as preferred etypes (Note: while MIT krb5 clients treat RC4 and 3DES as deprecated but not weak, their KDC only generates AES keys by default). Therefore it's unlikely user needs to enable any weak etypes.

      For users that have to use a weak etype, they will need to modify both allow_weak_crypto and permitted_enctypes. If they are also a user of a modern MIT krb5, they should have already done so.
      Show
      Modern Kerberos servers (Windows 2008 and later, MIT krb5 since 2004) already use AES as preferred etypes (Note: while MIT krb5 clients treat RC4 and 3DES as deprecated but not weak, their KDC only generates AES keys by default). Therefore it's unlikely user needs to enable any weak etypes. For users that have to use a weak etype, they will need to modify both allow_weak_crypto and permitted_enctypes. If they are also a user of a modern MIT krb5, they should have already done so.
    • Interface Kind:
      File or wire format
    • Scope:
      Implementation

      Description

      Summary

      Remove the weak encryption types from the default etype list.

      Problem

      There are 2 settings in krb5.conf to control what encryption types are enabled:

      1. permitted_enctypes is a list of etype names
      2. allow_weak_crypto is a boolean flag that can be used to filter out weak crypto like DES and RC4 from the list under permitted_enctypes.

      Before the current proposal, allow_weak_crypto is by default false and permitted_enctypes by default contains all strong and weak supported etypes.

      This has been working fine before JDK-8139348 (Deprecate 3DES and RC4 in Kerberos) where the only weak etype is DES. If a user doesn't use DES, they can just use the default settings. Otherwise, set allow_weak_crypto = true to enable DES.

      However, after JDK-8139348 we have more weak etypes, i.e. 3DES and RC4. If a user wants to enable RC4, it's very likely they simply set allow_weak_crypto = true which also enables DES. The correct way is to set allow_weak_crypto = true and use a permitted_enctypes setting which contains RC4 but not DES.

      In order to prevent the above scenario of enabling DES by accident, we propose to change the default value of permitted_enctypes to only contains the strong ones. This means to enable a weak etype, users must set allow_weak_crypto to true and add the weak etype to permitted_enctypes setting.

      The reference Kerberos 5 implementation -- MIT krb5 -- has already removed weak etypes from the default permitted_enctypes setting. See https://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/krb5_conf.html. Please note that they only consider DES to be weak so their default list does not contain DES but still contain RC4 and 3DES. The various etypes they support can be found at https://web.mit.edu/kerberos/krb5-devel/doc/admin/conf_files/kdc_conf.html#encryption-types.

      Solution

      Remove weak etypes from default enctypes list. Please note there will be no behavior change by default, where allow_weak_crypto is false.

      Specification

      Update the last section in "Security Developer's Guide" (see https://docs.oracle.com/en/java/javase/17/security/kerberos-5-gss-api-mechanism.html for jdk17 version) and change the default value of permitted_enctypes to "aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128" instead of which means all supported etypes (strong and weak).

      For jdk8u, where aes-sha2 was not supported, the default value of permitted_enctypes will be "aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96".

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              weijun Weijun Wang
              Reporter:
              weijun Weijun Wang
              Reviewed By:
              Valerie Peng
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: