RFR 8168518: rcache interop with krb5-1.15
Wang Weijun
weijun.wang at oracle.com
Tue Oct 25 07:36:47 UTC 2016
Hi Xuelei
I rethink about it. Here is the updated webrev:
http://cr.openjdk.java.net/~weijun/8168518/webrev.01/
Changes from webrev.00:
1. Default value is now SHA256. This is also the same default for latest MIT krb5.
2. User can only revert it to HASH with a boolean system property. No more free setting.
3. Test fixed. I forgot to pass the system property to child process.
Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8168635.
Thanks
Max
> On Oct 25, 2016, at 1:46 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>
>
>
> On 10/25/2016 1:40 PM, Xuelei Fan wrote:
>> Is the "HASH" algorithm a new name? I'm not sure why introduce this
>> none-standard name.
>
> HASH is actually MD5, it is the label used by MIT krb5 in its previous releases. In 1.15, it's SHA256. I just want it to the same with MIT krb5.
>
>> 39 // The hash algorithm can be "HASH" or "SHA256".
>> What if the algorithm is not one of the two? Why not use the standard
>> names? Do you want to support SHA3?
>
> No.
>
> The system property is not meant to be fully customizable. The only usage is that you can set it to SHA256 if you want full krb5-1.15 interoperability. I mainly created it so I can test on it.
>
>>
>> As the DEFAULT_HASH_ALG system property is customizable, the value may
>> be not valid. Therefore, the AssertionError may be too strong to use in
>> line 310 of KrbApReq.java, and the message can have more information.
>
> OK, I'll change the message.
>
>
>>
>> Otherwise, looks fine to me.
>>
>> Xuelei
>>
>> On 10/25/2016 12:18 PM, Wang Weijun wrote:
>>> http://cr.openjdk.java.net/~weijun/8168518/webrev.00/
>>>
>>> Please read https://bugs.openjdk.java.net/browse/JDK-8168518 for the
>>> reason. This code change includes:
>>>
>>> 1. Add a hashAlg field in AuthTimeWithHash.java.
>>>
>>> 2. Add AuthTimeWithHash.DEFAULT_HASH_ALG so we can change it later.
>>>
>>> 3. The fix of the bug is inside DflCache.java:
>>>
>>> @@ -300,7 +302,7 @@
>>>
>>> if (time.equals(a)) {
>>> // Exact match, must be a replay
>>> throw new KrbApErrException(Krb5.KRB_AP_ERR_REPEAT);
>>>
>>> - } else if (time.isSameIgnoresHash(a)) {
>>> + } else if (time.sameTimeDiffHash((AuthTimeWithHash)a)) {
>>>
>>> // Two different authenticators in the same second.
>>> // Remember it
>>> seeNewButNotSame = true;
>>>
>>> When a AuthTimeWithHash is seen with a different hash, we believe it's
>>> a new one. Before this fix, we simply compare the HASH string. Now
>>> that the algorithm can be different, we only treat it a new one if the
>>> algorithm is the same and the hash value is different.
>>>
>>> This code change has not tried to understand what a different hashAlg
>>> means and try to re-calculate with it. It is just treated as unknown.
>>>
>>> Tests updated. ReplayCacheTestProc.java enhanced so it can be called
>>> with some special system properties to test interop between a
>>> non-system-default native library or even between 2 different native
>>> libraries.
>>>
>>> Thanks
>>> Max
>>>
>>>
>>>
>>>
>>>
More information about the security-dev
mailing list