Created attachment 987549 [details] Wireshark capture of KRB5 communication IBM JDK has a bug in its KRB5 implementation. It uses Address type 23 for IPv6 addresses. The RFC-4120 specifies in section 7.5.3 that IPv6 address type has value 24. https://tools.ietf.org/html/rfc4120#section-7.5.3 ApacheDS Kerberos server after receiving TGS-REQ message with this wrong address type returns KRB-ERROR message with error code 41 (KRB5KRB_AP_ERR_MODIFIED). The problem occurs during client's call GSSContext.initSecContext() method. Steps to Reproduce: Use a Java client to ask for Kerberos ticket for EAP (e.g. HTTP.example). Additional info: If I change the address type value in debugger to 24 it starts to work as expected. The problem seems to be in com.ibm.security.krb5.internal.HostAddress.getAddrType(InetAddress) method: /* */ private int getAddrType(InetAddress inetAddress) /* */ { /* 118 */ int addressType = 0; /* 119 */ if ((inetAddress instanceof Inet4Address)) /* 120 */ addressType = 2; /* 121 */ else if ((inetAddress instanceof Inet6Address)) /* 122 */ addressType = 23; /* 123 */ return addressType; /* */ } Important part of the call stack: [1] com.ibm.security.krb5.internal.HostAddress.<init> (HostAddress.java:212) [2] com.ibm.security.krb5.HostAddresses.<init> (HostAddresses.java:85) [3] com.ibm.security.jgss.mech.krb5.Krb5Context.getDelgCreds (Krb5Context.java:2,472) [4] com.ibm.security.jgss.mech.krb5.Krb5Context.initSecContext (Krb5Context.java:616) [5] com.ibm.security.jgss.mech.krb5.Krb5Context.initSecContext (Krb5Context.java:805) [6] com.ibm.security.jgss.mech.spnego.SPNEGOContext.createInitToken (SPNEGOContext.java:1,146) [7] com.ibm.security.jgss.mech.spnego.SPNEGOContext.initSecContext (SPNEGOContext.java:529) [8] com.ibm.security.jgss.GSSContextImpl.initSecContext (GSSContextImpl.java:382) [9] com.ibm.security.jgss.GSSContextImpl.initSecContext (GSSContextImpl.java:331) [10] org.jboss.as.test.integration.security.common.negotiation.JBossNegotiateScheme.authenticate (JBossNegotiateScheme.java:171) [11] org.apache.http.client.protocol.RequestAuthenticationBase.authenticate (RequestAuthenticationBase.java:120) [12] org.apache.http.client.protocol.RequestAuthenticationBase.process (RequestAuthenticationBase.java:83) [13] org.apache.http.client.protocol.RequestTargetAuthentication.process (RequestTargetAuthentication.java:80) [14] org.apache.http.protocol.ImmutableHttpProcessor.process (ImmutableHttpProcessor.java:131) [15] org.apache.http.protocol.HttpRequestExecutor.preProcess (HttpRequestExecutor.java:165) [16] org.apache.http.impl.client.DefaultRequestDirector.execute (DefaultRequestDirector.java:485) [17] org.apache.http.impl.client.AbstractHttpClient.doExecute (AbstractHttpClient.java:863) [18] org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:82) [19] org.apache.http.impl.client.CloseableHttpClient.execute (CloseableHttpClient.java:106) [20] org.jboss.as.test.integration.security.common.Utils$2.run (Utils.java:525) [21] org.jboss.as.test.integration.security.common.Utils$2.run (Utils.java:523) [22] java.security.AccessController.doPrivileged (AccessController.java:366) [23] javax.security.auth.Subject.doAs (Subject.java:572) [24] org.jboss.as.test.integration.security.common.Utils.makeCallWithKerberosAuthn (Utils.java:523) [25] org.jboss.as.test.integration.security.loginmodules.negotiation.SPNEGOLoginModuleTestCase.testAuthn (SPNEGOLoginModuleTestCase.java:157) ...
Hello Red Hat, ... quick question: which IBM Java version are you using in your tests ..? Please advise ... Thanks for your support.
(In reply to Hanns-Joachim Uhl from comment #4) > Hello Red Hat, > ... quick question: which IBM Java version are you using in your tests ..? > Please advise ... > Thanks for your support. . Hello Red Hat, ... with RHEL7.2 GA now and with the most current IBM Java(s) available with it is this bugzilla still an issue or can it be closed ...? Please advise .. Thanks for your support.
Romain Pelisse <belaran> updated the status of jira JBEAP-733 to Coding In Progress
Romain Pelisse <belaran> updated the status of jira JBEAP-733 to Closed
------- Comment From chavez.com 2016-02-02 12:05 EDT------- (In reply to comment #8) > Romain Pelisse <belaran> updated the status of jira JBEAP-733 to > Coding In Progress > > Romain Pelisse <belaran> updated the status of jira JBEAP-733 to > Closed Hello, It isn't clear to me what the above means. Is there still a problem and do you need IBM Java L3 to help fix it? Thanks.
Romain close issue as not issue of EAP. Issue is still there, trying on [mchoma@localhost tests-ldap-kerberos]$ java -version java version "1.8.0" Java(TM) SE Runtime Environment (build pxa6480sr2-20151023_01(SR2)) IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20151019_272764 (JIT enabled, AOT enabled) J9VM - R28_Java8_SR2_20151019_2144_B272764 JIT - tr.r14.java_20151006_102517.04 GC - R28_Java8_SR2_20151019_2144_B272764_CMPRSS J9CL - 20151019_272764) JCL - 20151022_01 based on Oracle jdk8u65-b17 Should be fixed? Is there any public source we can watch progress?
------- Comment From chavez.com 2016-04-07 14:42 EDT------- The Java security team is working to resolve this. APAR IV83529 has been opened and once it is closed with a solution or other news, will update the bug again.
Created attachment 1144881 [details] test fix ------- Comment on attachment From chavez.com 2016-04-07 16:36 EDT------- The Java L3 security team provided me with a test fix. Can Red Hat please try it?
Hi, with patch I have tested SPNEGO works well on ipv6. One test failed (identity propagation), but it can be testing enviroment issue. I will investigate further. Martin For testing I have "patched" java 7, build pxa6470_27sr3fp30-20160112_01(SR3 FP30).
------- Comment From chavez.com 2016-04-08 23:18 EDT------- Response from Java L3 below. BTW, I will check in 2 and 3 weeks the status of the APAR mentioned. I'm glad that the jar resolved the problem. As I said in my previous update, we created APAR IV83529 to address this problem. Right now, we have to make the QA testing before we close the APAR. We take 3-4 weeks to do this. After the APAR is closed, you'll be able to see which JVM version will include the official fix. If you cannot wait for the JVM release, you can open a new PMR and request an iFix so it can be applied on top of the newest JVM available at that moment. Please let me know if there's anything else we can do for you. If not, can we close this PMR?
Mentioned identity propagation issue seems to be ApacheDS problem, which we use for testing. Testing with Active directory 2008R2 or 2012R2 shows no issues. I raised issue against ApacheDS https://issues.apache.org/jira/browse/DIRSERVER-2139.
We confirm, the fix works for us. We'll wait for the JVM versions with the official fix included. Thanks.
------- Comment From chavez.com 2016-05-02 11:19 EDT------- According to http://www-01.ibm.com/support/docview.wss?crawler=1&uid=swg1IV83529 the APAR was closed last week and lists 1.8.0 SR3FP10 as the expected official release. I don't see it out there yet.
fyi ... IBM Java 1.8.0 SR3 FP10 as well as IBM Java 7 SR9 FP50 were released at 07/26/2016 at http://www.ibm.com/developerworks/java/jdk/linux/download.html ...
(In reply to Hanns-Joachim Uhl from comment #18) > fyi ... IBM Java 1.8.0 SR3 FP10 as well as IBM Java 7 SR9 FP50 > were released at 07/26/2016 at > http://www.ibm.com/developerworks/java/jdk/linux/download.html ... . fyi ... . IBM Java 1.8.0 SR3 FP10 (for RHEL6 and RHEL7) is available from RHN since 08/10/2016 ... ... please see https://access.redhat.com/errata/RHSA-2016:1587 ... . IBM Java 7 SR9 FP50 (for RHEL5 only) is available from RHN since 08/10/2016 ... ... please see https://access.redhat.com/errata/RHSA-2016:1589 ... . ... please retest as soon as possible whether this bugzilla is resolved ...
I can confirm I dont see this issue with IBM Java 1.8.0 SR3 FP10 and IBM Java 7 SR9 FP50 any more.
Closing as NOTABIG since the latest java fixes this.