1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.KERBEROS

  • GSSAPI sequence numbers

    From Jake Scott@21:1/5 to All on Fri Mar 26 15:26:30 2021
    Hi..

    I am writing a native Golang implementation of GSSAPI, first for krb5 -
    using Johnathan Turner's library (https://github.com/jcmturner/gokrb5).

    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.

    Looking at the Heimdal and Java code, it appears that my naive approach is
    in use there unless I'm missing something glaringly obvious, and I can't
    find mention in the RFC about any different encoding.

    Could someone explain what the correct method is? If I'm missing a pointer
    in a doc somewhere please let me know. Is MIT 'correct' technically or
    maybe just by convention?

    My current implementation is here :
    https://github.com/jake-scott/go-gssapi/tree/v0

    .. and the 'workaround' to make sequence numbers compatible with MIT :


    // stash the sequence number for use in GSS Wrap
    var seqTmp int32 = int32(auth.SeqNumber)
    m.ourSequenceNumber = uint64(seqTmp)


    Any info gratefully received..

    Many thanks

    Jake

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Hudson@21:1/5 to Jake Scott on Fri Mar 26 17:17:27 2021
    To: kerberos@mit.edu

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Robbie Harwood@21:1/5 to Jake Scott on Fri Mar 26 22:19:48 2021
    To: kerberos@mit.edu

    Jake Scott <jake@poptart.org> writes:

    I am writing a native Golang implementation of GSSAPI, first for krb5 -
    using Johnathan Turner's library (https://github.com/jcmturner/gokrb5).

    Unless this is never to see production, I would be remiss if I didn't
    suggest you not use the pure Go implementation. I suggest you call
    libgssapi instead. The pure Go is not close to feature parity with any
    major Kerberos implementation, nor does it interoperate well.

    Thanks,
    --Robbie

    -----BEGIN PGP SIGNATURE-----

    iQJIBAEBCgAyFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAmBelkUUHHJoYXJ3b29k QHJlZGhhdC5jb20ACgkQJTL5F2qVpEIurRAAk+JfpHgvoyaCg4wdtvoJ/84eynp7 rYpg+7m9C1D6yCBPqsWv6k0qF155eEOQ7I2L9+OGdJz0eOp3pV6hY5zAX0iz2mXg ouDUsL0/RebEebmiJWPkuJ5BdpdmU9SGlUdjoZiKCFxIJDcuV0OY7oPWMrf8e8XW hmjuWiw8jRkQJZ5Uuj/bEA86VVVGgBz6Gdgi8Bn6z1Jjkzzm/ry5d8GD8ez1fG/B TEFJMh0ISKSAMlHKKJwbPONBo4MsPZDgL1j35Hh7ItMrFXGeXfasL+paNI3cTbN8 Tiu/1mXZ359BrMcT2d7kLHI5V5887fRy+WTQmeLTnHsCjqJK/sXryUORo1pqh7hE hbR6X3MyK6r/isgPwy//jQB22EW2CJd+YRKJ4C2gSs8ipGv9DHeiVW4ZWsGVOko2 4dNvDFljAtPJD+GBtfsjtYBsa30Vivhk761TXmoYpcScOgaEJ+FRqv65c2g6z36Z ypLDDfnUVGDmxxoQr9VNAmVBvcuc07s/lPFp92gjrbYpaVIHlnSPt5nl4IyPpFab r4DgJG2YmfQovT+rk9m9kMyFxJwlg+QX57+qehEiLAktuGJKLfdjN9BXU2XUkXXP 7Wutd0ITFKSxfXFwBL9p8niLxmzldZOs0Gs0/+EPoLfXG5LKB/5hKl/QBNGMSrsf yDo0fpHualVbkXY=
    =QAtN
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jake Scott@21:1/5 to Greg Hudson on Sat Mar 27 11:46:26 2021
    Copy: kerberos@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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)