GSSAPI sequence numbers

[Jake Scott]

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 <ghudson at 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.
>