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

[Valerie Peng]

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