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

Kerberos sequence number issues

    Details

    • Type: CSR
    • Status: Closed
    • Priority: P3
    • Resolution: Approved
    • Fix Version/s: 11
    • Component/s: security-libs
    • Labels:
      None
    • Subcomponent:
    • Compatibility Kind:
      behavioral
    • Compatibility Risk:
      low
    • Compatibility Risk Description:
      Hide
      This is a bug fix. If a user has been using the sequence numbers they should have noticed this problem.
       
      However, there has been no external report to this bug. Most likely because:
       
      1. Authentication is mutual by default for Kerberos 5.
       
      2. A lot of applications only perform an authentication (i.e. establishing a security context) and do no secure communication. Therefore sequence number is not used.
       
      3. The detection of abnormal sequence numbers is not mandated. For example, calling "unwrap(byte[] input, MessageProp prop)" will succeed even if the sequence number does not match the expected value. The application must explicitly call various MessageProp methods (Ex: isUnseqToken, isOldToken, isDuplicateToken, isGapToken) to find it out. Many applications do not care about the sequence number order because they maintain data integrity in the application protocol.
      Show
      This is a bug fix. If a user has been using the sequence numbers they should have noticed this problem.   However, there has been no external report to this bug. Most likely because:   1. Authentication is mutual by default for Kerberos 5.   2. A lot of applications only perform an authentication (i.e. establishing a security context) and do no secure communication. Therefore sequence number is not used.   3. The detection of abnormal sequence numbers is not mandated. For example, calling "unwrap(byte[] input, MessageProp prop)" will succeed even if the sequence number does not match the expected value. The application must explicitly call various MessageProp methods (Ex: isUnseqToken, isOldToken, isDuplicateToken, isGapToken) to find it out. Many applications do not care about the sequence number order because they maintain data integrity in the application protocol.
    • Interface Kind:
      System or security property
    • Scope:
      JDK

      Description

      Summary

      Introduce a system property to determine how to choose the initial sequence number if the acceptor has not sent one during a non-mutual Kerberos 5 authentication.

      Problem

      According to RFC 4121, during the Kerberos 5 security context establishment, the initiator (client) and the acceptor (server) will inform each other a sequence number. After the security context is established, each side would include (and increment) its own sequence number when sending a message, so that the peer can detect if the message is out of order.

      The security context establishment involves 2 messages: AP-REQ from initiator to acceptor, and AP-REP backwards.

      If non-mutual authentication is requested (by default, authentication is mutual), there will be no AP-REP, i.e. no channel to transmit the acceptor's initial sequence number.

      MIT krb5 and Microsoft assume it's the same as the initiator's initial sequence number. Heimdal (another popular krb5 implementation which is shipped with macOS) assumes 0. So they do not interop with each other. This can be observed with a simple test.

      Java used the initiator's initial sequence number on its acceptor side, but assumes it's zero on its initiator side. Thus it can interop with neither correctly. It even cannot interop with itself. See compatibility risk below to find out why this hasn't been a disaster.

      Solution

      Introduce a system property to choose which assumption to make.

      Specification

      This is not a Java SE interface.

      When mutual auth is not requested by the Kerberos 5 initiator, there is no way to negotiate acceptor's initial sequence number. In this case, if the system property "sun.security.krb5.acceptor.sequence.number.nonmutual" is set to "initiator", both initiator and acceptor assume the acceptor's initial sequence number is the same as the one from initiator. If set to "zero" or "0", both assume it to be 0. The default value is "initiator". All other values are illegal and will trigger an error when the system property is read.

      The system property will be documented in https://wiki.se.oracle.com/display/~rgallard/JDK+Security+Admin+Guide+-+Notes and we are considering adding it (along with some other useful ones from the wiki page) to the next version of https://docs.oracle.com/javase/10/security/kerberos-5-gss-api-mechanism.htm.

        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: