RFR 8160818: GssKrb5Client violates RFC 4752

Michael Osipov 1983-01-06 at gmx.net
Thu Feb 20 18:41:24 UTC 2020


Am 2020-02-20 um 03:57 schrieb Weijun Wang:> Ping again.
 >
 >> On Feb 14, 2020, at 10:51 PM, Weijun Wang <weijun.wang at oracle.com>
wrote:
 >>
 >>
 >>
 >>> On Feb 14, 2020, at 9:42 PM, Michael Osipov <1983-01-06 at gmx.net> wrote:
 >>>
 >>> Am 2020-02-14 um 10:58 schrieb Weijun Wang:
 >>>> Webrev updated at
 >>>>
 >>>>   https://cr.openjdk.java.net/~weijun/8160818/webrev.01
 >>>
 >>> This changes looks fine to me according to the RFC.
 >>>
 >>> Can this be backported to Java 8? Seems like a no-brainer.
 >>
 >> I'll ask the sustaining team.
 >>
 >> At the same time, can you tell me why this is suddenly urgent? I
don't know which item in [1] is enforcing the check. I'll be happy to
use your explanation as a justification for the backport.
Yes, sure. JDK-8160818 existed eversince I have engaged with JNDI and
LDAP. I am the reporter of the bug. The problem is two-fold:

1. The SASL GSSAPI mech requires at least auth-int to be present
2. "Signing" as called by MS is auth-int. If this is enabled via GPO on
all domain controllers people's code will start to fail because the
default mech configuration is faulty. Most will not start to analyze
with Wireshark because it is too complex. The will start to panic. To
avoid such a situation a proper/correct default needs to be set.

For that reason, I have added a workaround in my public wrapper lib [1]
until this is fixed.

[1]
http://dirctxsrc.sourceforge.net/xref/net/sf/michaelo/dirctxsrc/DirContextSource.html#L289

Michael


More information about the security-dev mailing list