JDK-7067974 : multiple ETYPE-INFO-ENTRY with same etype and different salt
  • Type: Bug
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-07-16
  • Updated: 2013-01-08
  • Resolved: 2011-09-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8
6u34Fixed 7u2Fixed 8 b06Fixed
Related Reports
Relates :  
Description
There is a bug in MIT's krb5 implementation that when preauth is needed, the KRB-ERROR message as the initial response to a AS-REQ without preauth info might contain multiple ETYPE-INFO(2)-ENTRYs with the same etype but different salt in the padata ETYPE-INFO(2). Furthermore, if krb4 is enabled, one of the salt might be different from the default krb5 salt.

We have a customer who PA-ETYPE-INFO contains these entries. Note that the customer has not made any special configuration to the KDC.

   Entry 1: des-cbc-null, no salt
   Entry 2: des-cbc-null, salt = ""
   Entry 3: des-cbc-null, salt = "REALM"

Before 6959292, we simply read the first entry, since there is no salt here, the default one is used snd it's good. After that, we read all entries and find one salt which is neither empty nor missing, and the wrong salt in Entry 3 is used.

The reason for 6858292 is because we are seeing this PA-ETYPE-INFO on Windows:

   Entry 1: rc4-hmac, no salt
   Entry 2: des-cbc-null, salt = "REALMuser"

In JDK 6, we do not save different salts for different etypes, and we only save one. So we read all entries and choose a salt which is neither missing nor empty.

The suggested fix is:

On JDK 7 and 8, we already save different salts for different etypes, so we should only save the salt of the first apppearance for the etype. This is consistent with the MIT krb5 and Heimdal behavior.

On JDK 6 (or earlier), we still save only one salt, and --
1. For duplicated etypes, we save the first appearance
2. For different etypes, we save the non-empty and non-missing one

Comments
regression test DupEtypes.java passes on nightly runs and no failures in the last 15 days
08-01-2013

EVALUATION http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c62794c9caea
07-09-2011