United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7061379 [Kerberos] Cross-realm authentication fails, due to nameType problem
JDK-7061379 : [Kerberos] Cross-realm authentication fails, due to nameType problem

Details
Type:
Bug
Submit Date:
2011-07-01
Status:
Closed
Updated Date:
2014-03-26
Project Name:
JDK
Resolved Date:
2011-08-16
Component:
security-libs
OS:
linux_redhat_4.0,linux
Sub-Component:
org.ietf.jgss:krb5
CPU:
x86
Priority:
P4
Resolution:
Fixed
Affected Versions:
6,6u29
Fixed Versions:

Related Reports
Backport:
Backport:
Duplicate:

Sub Tasks

Description
FULL PRODUCT VERSION :
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02, mixed mode)

/!\ same bug with open jdk 1.7

ADDITIONAL OS VERSION INFORMATION :
Linux x86_64 Intel(R) Xeon(R) CPU L5520  @ 2.27GHz GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
/!\ same bug with open jdk 1.7

A DESCRIPTION OF THE PROBLEM :
Authentication to remote server fails. Error doesn't appear in the logs but the debugger points out the following error:

KRB_AP_ERR_MODIFIED (erreur 41) Message stream modified
in sun.security.krb5.KrbKdcRep class, line 56

Cross-realm authentication to one remote service is processed in
sun.security.krb5.internal.CredentialsUtil class.
It consists in the obtention of a token for the krbtgt/REALM1@REALM2 principal.

Function acquireServiceCreds() negotiates with the kdc, by throwing requests and receiving responses. equalsWithoutRealm() function is called.

The function equalsWithoutRealm() in sun.security.krb5.PrincipalName checks the conformity between principal asked in request and principal obtained in response.
However, there is a type mismatch between the two krbtgt principals: request asks for a KRB_NT_SRV_INST type whereas the kdc answers with a KRB_NT_PRINCIPAL type. Thus, equalsWithoutRealm function fails and authentication is refused.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Try to access from one realm to whatever remote 'kerberized' service.
For example: GSSAPI and JNDI for remote LDAP server.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Expected result: successful authentication with remote service access.
ACTUAL -
Error is caught but not reported in system.out, and remote authentication fails.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
KRB_AP_ERR_MODIFIED (erreur 41) Message stream modified
in sun.security.krb5.KrbKdcRep class, line 56

is reached but never thrown to the logs.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Modifying the acquireServiceCreds() function solves the problem. But maybe the best solution is to change the request for a cross-realm krbtgt.

Line 134 in CredentialsUtil.java:

for (cTgt = ccreds, i = 0; i < realms.length;)
        {
//            tempService = new ServiceName(PrincipalName.TGS_DEFAULT_SRV_NAME,
//                                          serviceRealm, realms[i]);
			if (!localRealm.equalsIgnoreCase(serviceRealm)) { //do cross-realm authentication
				if (DEBUG) {
					System.out.println(">>>DEBUG: Credentails request cross realm ticket for " + "krbtgt/" + serviceRealm + "@" + localRealm);
				}
				tempService = new ServiceName("krbtgt/" + serviceRealm + "@" + realms[i]);
			}else{
				tempService = new ServiceName(PrincipalName.TGS_DEFAULT_SRV_NAME,
						serviceRealm, realms[i]);
			}

            if (DEBUG)
            {
                System.out.println(">>> Credentials acquireServiceCreds: main loop: [" + i +"] tempService=" + tempService);
            }
...
...
...

SUPPORT :
YES

                                    

Comments
EVALUATION

http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e68db408d08c
                                     
2011-08-04
EVALUATION

The bug report says the TGS-REQ "asks for a KRB_NT_SRV_INST type whereas the kdc answers with a KRB_NT_PRINCIPAL type. Thus, equalsWithoutRealm function fails and authentication is refused". The KDC's behavior is a little abnormal but RFC 4120 6.2 [1] does point out:

   ... The name-type SHOULD be
   treated only as a hint to interpreting the meaning of a name.  It is
   not significant when checking for equivalence.

So I remove the name-type check in PrincipalName.equalsWithoutRsealm(). This also makes equals() transitive, which is good. The hashCode() method has never been dependent on the name-type, so there is no need to update it.

The regression test introduced a new KDC option to set name-type for sname in a KDC-REP to be an arbitrary value, in order to prove it is now ignored in "checking for equivalence".
                                     
2011-08-04
provided test cases have passed in 1.8
                                     
2013-06-17



Hardware and Software, Engineered to Work Together