Re: RFR 8078439: Kerberos auth fails if client proposes MS krb5 OID

[Valerie Peng]

Looks good to me.
Thanks,
Valerie

On 4/30/2015 2:06 AM, Weijun Wang wrote:

Hi Valerie

I've updated the test a little to make sure the exception is NO_CRED and it's sent from the krb5 mech.

It passed on my own machine and I'm running a JPRT job now.

The webrev is at http://cr.openjdk.java.net/~weijun/8078439/webrev.02/

Thanks
Max

On 4/30/2015 9:37 AM, Valerie Peng wrote:

I think your current approach of using the mechList[0] makes sense. As
long as the rest of our code will recognize this MS krb5 OID, it will be
fine.

The source changes look fine to me.
Just some nits on the regression test "MSOID.java":
1) line 57 has a typo, aceptor -> acceptor
2) line 59, currently, this test will accept all GSSException as the
expected exception which may be a little bit too liberal. Any chance
that we can narrow it down to a certain error status code? Just so we
don't accidentally allow the wrong exceptions.

Thanks,
Valerie

On 4/25/2015 7:21 PM, Weijun Wang wrote:

Hi All

I've updated the webrev at

   http://cr.openjdk.java.net/~weijun/8078439/webrev.01/

The only change is

@@ -548,6 +548,7 @@
                                 "mechToken is missing");
                     }
                     accept_token = GSS_acceptSecContext(mechToken);
+                    mech_wanted = mechList[0];
                 } else {
                     accept_token = null;
                 }

This means the supportedMech in response will be MS_KRB5_OID if it was
the preferred mech in the request.

In my webrev.00, I insisted using the "correct" OID  because that was
the way before JDK-8048194 and no one complained about it. Therefore I
think the client side is able to find out that it's also a flavor of

Kerberos 5 and has accepted it happily. So why fix it if it's not broken?

However, after writing a SSPI client myself, I find out that it does
not accept the "correct" ID and fail. Why didn't people notice that?
My understanding is that until now a client that sends those OIDs has
always been a browser, and this browser simply ignores the response if
it already sees a "200 OK" HTTP status.

Thanks
Max

On 4/25/2015 12:19 PM, Weijun Wang wrote:

Hi All

Please review a fix at

    http://cr.openjdk.java.net/~weijun/8078439

This is a regression triggered by JDK-8048194. In SPNEGO, a client might

send NegTokenInit with OIDs being {MS_KRB5_OID, KRB5_OID} along with a

krb5 AP-REQ as mechToken. Java did not understand MS_KRB5_OID but before

JDK-8048194 it blindly accepted the mechToken and everything just went
on fine. After JDK-8048194, it rejects the unknown OID and cannot
establish a security context.

The fix adds a tweak to recognize the MS_KRB5_OID.

*Ivan*:

Can you try out the patch on jdk8u?

Thanks
Max