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

Problem with keytabs with multiple kvno's (key versions)

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P3
    • Resolution: Won't Fix
    • Affects Version/s: 6
    • Fix Version/s: 6-pool
    • Component/s: security-libs
    • Labels:

      Backports

        Description

        FULL PRODUCT VERSION :
        java version "1.6.0_10"
        Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
        Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)


        ADDITIONAL OS VERSION INFORMATION :
        $ uname -a
        Linux XXXXX 2.4.21-32.0.1.EL.msdwhugemem #1 SMP Mon Dec 5 21:32:44 EST 2005
        i686 i686 i386 GNU/Linux


        A DESCRIPTION OF THE PROBLEM :
        A java application using JGSS to accept kerberos contexts (service tickets)
        cannot decrypt them (apparently) and fails accepting the context with a
        "Checksum failed !" message on System.err.

        From experimenting it appears that this is due to the code being confused
        by older keys (lower numerical KVNOs) present in the keytab files (lower
        KVNOs can be present due to e.g. keys rotation). It seems that the JGSS code
        is confused by this and doesn't select the right key. Possibly this could be
        due to the code wrongly assuming KVNOs are in ascending order in the keytab
        file, while this is not necessarily the case.

        Using and MIT implementation of kerberos, the same client can connect fine
        to a server using the same keytab file, proving there is nothing wrong with
        the client nor the keytab file, and that the "Checksum failed !" message is
        bogus.

        For a given keytab file, this always fails.

        You can also see another report of this same issue in the forums @
        http://forums.sun.com/thread.jspa?threadID=5235085

        This makes it very hard to leverage JGSS kerberos in an enterprise
        environment with sophisticated key management.

        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        1) get keytabs with multiple KVNOs (depends on kerberos infrstructure, but
        can be achived by rotating keys and using ktutil to reorder keys to force a
        non ascending KVNO order, which is believed to trigger this bug).

        2) have a java program using JGSS attempt to accept a kerberos connection
        (token).

        3) See that depending on order in the keytab file, the decryption sometimes
        fails with a "Checksum failed !" message on System.err.

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        The JGSS implementation should be able to select the right key from the
        keytab file when attempting decryption.
        ACTUAL -
        The right key is selected from the keytab file and decryption succeeds.

        ERROR MESSAGES/STACK TRACES THAT OCCUR :
        Partial log:

        Commit Succeeded

        Found key for bob/###@###.###(xx)
        Found key for bob/###@###.###(xx)
        Found key for bob/###@###.###(xx)
        Found key for bob/###@###.###(xx)
        Found key for bob/###@###.###(xx)
        Found key for bob/###@###.###(xx)
        Found key for bob/###@###.###(xx)
        Found key for bob/###@###.###(xx)
        Entered Krb5Context.acceptSecContext with state=STATE_NEW
        EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
        Checksum failed !


        for security reasons only a partial log with obsfucated values is provided.
        If more information is necessary, please get in touch.

        REPRODUCIBILITY :
        This bug can be reproduced always.

        CUSTOMER SUBMITTED WORKAROUND :
        Manipulate keytab files with ktutil to remove keys with KVNOs lower than the
        highest. This is not desired and highly risky in production since it can
        potentially impact processes currently using lower KVNOs, hence cannot be
        performed safely in certain contexts.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  weijun Weijun Wang
                  Reporter:
                  weijun Weijun Wang
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  0 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: