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

[Weijun Wang]

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