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
