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.w...@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.w...@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.w...@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.p...@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 >>>>> >>>> >>> >> >
