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 >>>> >>> >> >
