RFR (+CSR) 8201627: Kerberos sequence number issues

[Weijun Wang]

> On May 15, 2018, at 8:32 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
> 
> Hi Max,
> 
> I think it'd be clearer to mention default behavior first and then mention the system property for overriding it if necessary. Something like following:
> 
> When mutual auth is not requested by the Kerberos 5 initiator, there is no way to negotiate acceptor's initial sequence number. With this fix, the SunJGSS provider will use initiator's initial sequence number as the initial sequence number. To override this default behavior and to use 0 instead, please set the system property "sun.security.krb5.acceptor.sequence.number.nonmutual" to "zero" or "0". Values other than "initiator", "zero", and "0" are illegal".

Great.

> 
> Maybe it'd also be nice to mention how the illegal values are handled, i.e. ignored, exception thrown, etc.

An error will be thrown.

Thanks
Max

> 
> Valerie
> 
> 
> On 5/4/2018 10:53 PM, Weijun Wang wrote:
>> Hi Valerie
>> 
>> Can you also review the release note at https://bugs.openjdk.java.net/browse/JDK-8202681?
>> 
>> Thanks
>> Max
>> 
>> 
>>> On Apr 27, 2018, at 5:58 AM, Valerie Peng <valerie.peng at oracle.com> wrote:
>>> 
>>> Sure, should be fine...
>>> Valerie
>>> 
>>> On 4/25/2018 9:48 PM, Weijun Wang wrote:
>>>> I filed https://bugs.openjdk.java.net/browse/JDK-8202300 but might not have time to make it into JDK 11.
>>>> 
>>>> --Max
>>>> 
>>>>> On Apr 26, 2018, at 12:06 AM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>> 
>>>>> I'll keep using int32 (at least in this fix), both Java and MIT krb5 contain these words
>>>>> 
>>>>> * Workaround implementation incompatibilities by not generating
>>>>> * initial sequence numbers greater than 2^30
>>>>> 
>>>>> So bad thing could only happen after 2^30 messages.
>>>>> 
>>>>> --Max
>>>>> 
>>>>>> On Apr 25, 2018, at 10:38 PM, Weijun Wang <weijun.wang at oracle.com> wrote:
>>>>>> 
>>>>>> It's complicated. Looks like MIT krb5 uses a uint32 for old etypes (DES, 3DES, RC4) and a uint64 for new ones (AES) [1][2].
>>>>>> 
>>>>>> I'll do more experiments.
>>>>>> 
>>>>>> Thanks
>>>>>> Max
>>>>>> 
>>>>>> [1] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/util_seqstate.c#L76
>>>>>> [2] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/init_sec_context.c#L825
>>>>>> 
>>>>>>> On Apr 24, 2018, at 8:55 PM, Wang Weijun <weijun.wang at oracle.com> wrote:
>>>>>>> 
>>>>>>> RFC 4120 5.5.1 has
>>>>>>>> seq-number
>>>>>>>> This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1.
>>>>>>> If it wraps, then it’s 4 bytes.
>>>>>>> 
>>>>>>> I will read more on it.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Max
>>>>>>> 
>>>>>>>> 在 2018年4月24日，18:08，Valerie Peng <valerie.peng at oracle.com> 写道：
>>>>>>>> 
>>>>>>>> Hi Max,
>>>>>>>> 
>>>>>>>> Most changes look good. I have only some comments and questions (see below):
>>>>>>>> 
>>>>>>>> - InitSecContextToken.java, line 62: bad -> unrecognized?
>>>>>>>> - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number?
>>>>>>>> 
>>>>>>>> CSR looks good to me.
>>>>>>>> Thanks,
>>>>>>>> Valerie
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 4/18/2018 10:40 AM, Weijun Wang wrote:
>>>>>>>>> Please take a review of this fix:
>>>>>>>>> 
>>>>>>>>> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/
>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814
>>>>>>>>> 
>>>>>>>>> Basically we fix some bugs and introduce a system property so we can interop with everyone.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Max
>>>>>>>>> 
>