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