Bug 1188632 - IBM JDK: Wrong IPv6 address type used in TGS-REQ during kerberos authentication
Summary: IBM JDK: Wrong IPv6 address type used in TGS-REQ during kerberos authentication
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Security
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: ---
Assignee: Darran Lofthouse
QA Contact: Josef Cacek
URL:
Whiteboard:
Depends On:
Blocks: 1230910
TreeView+ depends on / blocked
 
Reported: 2015-02-03 13:04 UTC by Josef Cacek
Modified: 2016-11-09 14:28 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-09 14:28:47 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Wireshark capture of KRB5 communication (3.43 KB, application/octet-stream)
2015-02-03 13:04 UTC, Josef Cacek
no flags Details
test fix (1010.46 KB, application/java-archive)
2016-04-07 20:44 UTC, IBM Bug Proxy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 131425 0 None None None Never
Red Hat Bugzilla 1189141 0 unspecified CLOSED Clean-up tests which use Kerberos in the EAP testsuite 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker JBEAP-733 0 Major Closed IBM JDK: Wrong IPv6 address type used in TGS-REQ during kerberos authentication 2018-04-04 02:51:21 UTC

Internal Links: 1189141

Description Josef Cacek 2015-02-03 13:04:02 UTC
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)
...

Comment 4 Hanns-Joachim Uhl 2015-10-06 16:11:55 UTC
Hello Red Hat,
... quick question: which IBM Java version are you using in your tests ..?
Please advise ...
Thanks for your support.

Comment 6 Hanns-Joachim Uhl 2016-01-26 09:23:32 UTC
(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.

Comment 7 JBoss JIRA Server 2016-01-26 18:41:52 UTC
Romain Pelisse <belaran> updated the status of jira JBEAP-733 to Coding In Progress

Comment 8 JBoss JIRA Server 2016-01-26 18:42:50 UTC
Romain Pelisse <belaran> updated the status of jira JBEAP-733 to Closed

Comment 9 IBM Bug Proxy 2016-02-02 17:11:56 UTC
------- 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.

Comment 10 mchoma 2016-02-03 12:28:20 UTC
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 11 IBM Bug Proxy 2016-04-07 18:51:08 UTC
------- 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.

Comment 12 IBM Bug Proxy 2016-04-07 20:44:08 UTC
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?

Comment 13 mchoma 2016-04-08 12:56:49 UTC
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 14 IBM Bug Proxy 2016-04-09 03:20:44 UTC
------- 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?

Comment 15 mchoma 2016-04-11 14:00:12 UTC
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.

Comment 16 Josef Cacek 2016-04-12 13:02:36 UTC
We confirm, the fix works for us. We'll wait for the JVM versions with the official fix included. Thanks.

Comment 17 IBM Bug Proxy 2016-05-02 15:21:26 UTC
------- 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.

Comment 18 Hanns-Joachim Uhl 2016-08-05 10:06:40 UTC
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 ...

Comment 19 Hanns-Joachim Uhl 2016-08-10 16:03:05 UTC
(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 ...

Comment 20 mchoma 2016-08-12 08:40:13 UTC
I can confirm I dont see this issue with IBM Java 1.8.0 SR3 FP10 and IBM Java 7 SR9 FP50 any more.

Comment 21 John Jarvis 2016-11-09 14:28:47 UTC
Closing as NOTABIG since the latest java fixes this.


Note You need to log in before you can comment on or make changes to this bug.