JDK-5006629 : Kerberos library should only select keys of types that it supports
  • Type: Bug
  • Component: security-libs
  • Sub-Component: org.ietf.jgss:krb5
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2004-03-02
  • Updated: 2004-09-09
  • Resolved: 2004-04-06
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.
Other
1.4.2_07Fixed
Description
The Java Kerberos library sometimes cannot use keytabs that contain keys of
encryption types that it does not support, even though the same keytabs
might contain keys of encryption types that it does support. The problem
is that when asked to get a key from the keytab for a service, the library
simply gets the last key from the keytab for that service. It does not
look for keys that it can support. Consequently, when it tries to use
the key, it gets an error.

This creates an interoperability issue. Java clients cannot use keytabs
generated by other systems that support other encryption types and happen
to put those keys after the DES keys.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_07 tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b44 tiger-b46 tiger-beta2
10-09-2004
SUGGESTED FIX The service key is obtained via the following code path: Krb5LoginModule.attemptAuthentication(); <- EncryptionKey.acquireSecretKey(principal, keyTabName); <- KeyTab.readServiceKey(principal); KeyTab.readServiceKey(principal) reads the *last* key entry from the keytab that matches the service principal name supplied. It doesn't check the keytype at that point, just records it. Later on, when the key gets used, say, in EncryptedData: EType etypeEngine = EType.getInstance(key.getEType()); It discovers that it doesn't have support for that keytype and then fails. It seems that an appropriate fix would be to check in readServiceKey() that the key being returned is one that can be supported instead just getting the last key in the keytab.
10-09-2004
EVALUATION Fix as suggested. ###@###.### 2004-03-02
02-03-2004