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