GSSAPI sequence numbers

[Greg Hudson]

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.