Thank you for the clarification.. this makes perfect sense now. I see there have been a number of iterations on the sequence number generation - at one point it was 0x5ffffff.
The work around of limiting ISNs to 2^30 is a better approach than supporting a 'compatibility' configuration flag which was going to be my fix. Hopefully a note on this can make it into a future RFC revision.. I sent a PR fixing this in the gokrb code base : https://github.com/jcmturner/gokrb5/pull/435 Many thanks Jake On Fri, Mar 26, 2021 at 5:17 PM Greg Hudson <ghud...@mit.edu> wrote: > On 3/26/21 3:26 PM, Jake Scott wrote: > > I took the naive approach of handling the initial sequence numbers by > > simply casting the uint32 value from the authenticator and AP-REP encpart > > to uint64. However that causes compatibility issues with the MIT > > implementation that appears to cast first to a signed int32 and then to > the > > GSSAPI uint64. > > I think that may have been a bug introduced in 2008. In release 1.6, > the GSSAPI code fetched the Kerberos sequence number into a uint32, but > using a function accepting an int32 *, which caused compiler warnings. > Commit abcfdaff756631d73f49103f679cafa7bc45f14e (later merged in commit > 0ba5ccd7bb3ea15e44a87f84ca6feed8890f657d) the warnings were squashed by > changing the variable to an int32, apparently without regard to the > behavior change for Kerberos sequence numbers in the 2^31..2^32-1 range. > > Due to earlier history with sequence number and ASN.1 encoding bugs, MIT > and Heimdal both generate Kerberos sequence numbers in the range > 0..2^30-1 by masking with 0x3FFFFFFF (see krb5_generate_seq_number() in > both implementations). I would speculate that Microsoft and Java do the > same. That could explain why the behavior change might have gone > unnoticed. > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
