RFR 8160818: GssKrb5Client violates RFC 4752

Weijun Wang weijun.wang at oracle.com
Fri Feb 21 07:40:53 UTC 2020



> On Feb 21, 2020, at 2:41 AM, Michael Osipov <1983-01-06 at gmx.net> wrote:
> 
> 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

Why?

> 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.

Has the fix for this bug avoided this problem? "auth" is still the default.

It looks this requires the default qop for SASL to be auth-int, or at least for the GSSAPI mechanism.

Thanks,
Max

> 
> For that reason, I have added a workaround in my public wrapper lib [1]
> until this is fixed.
> 
> [1]
> https://urldefense.com/v3/__http://dirctxsrc.sourceforge.net/xref/net/sf/michaelo/dirctxsrc/DirContextSource.html*L289__;Iw!!GqivPVa7Brio!IqTwdzAHnBvdqVVo_XepmDXCME5i6IpCfpwzy8ge2GmSZ7cZNnUb7jJH-zCEpaoURw$ 
> Michael




More information about the security-dev mailing list