JDK-6907425 : JCK Kerberos tests fail since b77
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 7
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2009-12-04
  • Updated: 2012-03-22
  • Resolved: 2010-01-08
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.
7 b79Fixed
Related Reports
Relates :  
Relates :  
Failing JCK tests:

JCK            : JCK 7 any
J2SE           : FAIL - JDK 7 b77, PASS - JDK 7 b76 
Platform[s]    : FAIL - Solaris 10 sparc and Windows 2003 amd64 tested.
switch/Mode    : FAIL - default

All tests fail with the same exception stack trace:

GSSException: Failure unspecified at GSS-API level (Mechanism level: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES128 CTS mode with HMAC SHA1-96)
	at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:758)
	at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:341)
	at javasoft.sqe.tests.api.org.ietf.jgss.GSSCredential.disposeServer$Action.run(dispose.java:218)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAsPrivileged(Subject.java:474)
	at javasoft.sqe.tests.api.org.ietf.jgss.GSSCredential.disposeServer.thisRun(dispose.java:163)
	at javasoft.sqe.tests.api.org.ietf.jgss.GSSCredential.disposeServer.run(dispose.java:109)
Caused by: KrbException: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - AES128 CTS mode with HMAC SHA1-96
	at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:275)
	at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:146)
	at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:108)
	at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:741)
	... 6 more

Steps to reproduce (run the JCK tests using jck4jdk) :

ag153348@nexus$ /java/re/jdk/7/promoted/ea/b77/binaries/solaris-sparc/bin/java -jar /java/re/jck/7/promoted/latest/binaries/JCK-runtime-7/lib/jtjck.jar -v api/org_ietf/jgss/GSSContext api/org_ietf/jgss/GSSCredential
Dec 4, 2009 6:46:52 AM Harness starting test run with configuration "jck_runtime_solaris"...
FAILED: api/org_ietf/jgss/GSSContext/index.html#getMICIOTest
FAILED: api/org_ietf/jgss/GSSContext/index.html#getDelegCredTest
FAILED: api/org_ietf/jgss/GSSContext/index.html#getMechTest
FAILED: api/org_ietf/jgss/GSSContext/index.html#exportTest
FAILED: api/org_ietf/jgss/GSSContext/index.html#isInitiatorTest
FAILED: api/org_ietf/jgss/GSSContext/index.html#isProtReadyTest
FAILED: api/org_ietf/jgss/GSSContext/index.html#wrapUnwrapIOTest
FAILED: api/org_ietf/jgss/GSSContext/index.html#setCBTest
FAILED: api/org_ietf/jgss/GSSCredential/index.html#addTest
FAILED: api/org_ietf/jgss/GSSCredential/index.html#equalsTest
FAILED: api/org_ietf/jgss/GSSCredential/index.html#disposeTest
FAILED: api/org_ietf/jgss/GSSCredential/index.html#getMechsTest
FAILED: api/org_ietf/jgss/GSSCredential/index.html#getTests
FAILED: api/org_ietf/jgss/GSSContext/index.html#SetGetTests
Dec 4, 2009 6:56:07 AM Finished executing all tests, wait for cleanup...
Dec 4, 2009 6:56:07 AM Harness done with cleanup from test run.
Test results: failed: 14
Results written to /home/ag153348/JCK-runtime-7_b28-work.
Error: Some tests did not pass
The JTR files are attached.

EVALUATION Solutiion: add a new method versionMatches(*,*), two kvno match if and only if: 1. Both are the same non-null and non-zero integer. 2. One of them is null or zero. Zero is treated as zero because javax.security.auth.kerberos.KerberosKey's kvno is int (not Integer), therefore, is using zero when converting from a EncryptionKey with null kvno.

EVALUATION http://hg.openjdk.java.net/jdk7/tl/jdk/rev/91c3cabb3d32

EVALUATION This is a regression introduced by code changes for 6893158. It seems in these tests, the keys on the KDC side have kvno info, but on the server side, keys are not read from keytab but generated with username/password pair and have no kvno info. Therefore, when the server receives a EncryptedData with kvno, it tries to locate a key in its keys set, and finds none with the same kvno value. Add a fallback mechanism to the findKey() method.