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

[Weijun Wang]

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