[38891] in Kerberos
Re: GSSAPI sequence numbers
daemon@ATHENA.MIT.EDU (Jake Scott)
Sat Mar 27 13:45:34 2021
MIME-Version: 1.0
In-Reply-To: <5982cc46-48d0-5be9-542c-d7a53bb0346a@mit.edu>
From: Jake Scott <jake@poptart.org>
Date: Sat, 27 Mar 2021 11:46:26 -0400
Message-ID: <CAExmWci-r1PO_kzKOScg0ZHqeJWn2X14fVKfdftbY_sAcfwt8A@mail.gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@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
