Java 1.5 is not encoding integers properly - Kerberos

This is a discussion on Java 1.5 is not encoding integers properly - Kerberos ; I am using java 1.5 to generate a service ticket token (AP Request) for a service running on Unisys machines. This token can not be parsed properly due to ASN encoding errors. There is an Authenticator in this AP request. ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Java 1.5 is not encoding integers properly

  1. Java 1.5 is not encoding integers properly

    I am using java 1.5 to generate a service ticket token (AP Request) for a
    service running on Unisys machines.
    This token can not be parsed properly due to ASN encoding errors.

    There is an Authenticator in this AP request.
    Within the authenticator, there is an optional field for seq-number of type
    integer.
    The seq-number is a unsigned integer that can go from 0 to 2**32 -1 with a
    random initial value.

    During my sample runs, I saw that Java 1.5 implementation is either sending
    an integer encoded in 2 bytes or an integer encoded in 4 bytes. When this is
    encoded in 2 bytes, there is no issue. When this is encoded in 4 bytes, the
    encoding is not correct. The value looks something like FFFFXXXX (A706 0204
    FFFFXXXX).

    As per ASN encoding, this should be encoded as 00FFFFXXXX (A707 0205
    00FFFFXXXX) since ASN encoding does not allow top 9 bit to be either all
    ones or all zeroes.

    Has anyone seen this problem?

    sample Hex dump of the seq-number field from the Authenticator

    A70402020398 Works
    A704020207CB Works
    A7060204FFFFF77F Fails
    A7060204FFFFFA59 Fails
    A7060204FFFFF96D Fails
    A7060204FFFFF3F8 Fails



  2. Re: Java 1.5 is not encoding integers properly

    Sun's implementation of Java GSS/Kerberos implementation is fully
    interoperable with MIT/Solaris/Linux/Windows GSS/Kerberos
    implementations. Tokens generated by Java are accepted by all other
    GSS/Kerberos implementations.

    I'll look into this, and get back to you.

    Seema

    Salil Dangi wrote:
    > I am using java 1.5 to generate a service ticket token (AP Request) for a
    > service running on Unisys machines.
    > This token can not be parsed properly due to ASN encoding errors.
    >
    > There is an Authenticator in this AP request.
    > Within the authenticator, there is an optional field for seq-number of type
    > integer.
    > The seq-number is a unsigned integer that can go from 0 to 2**32 -1 with a
    > random initial value.
    >
    > During my sample runs, I saw that Java 1.5 implementation is either sending
    > an integer encoded in 2 bytes or an integer encoded in 4 bytes. When this is
    > encoded in 2 bytes, there is no issue. When this is encoded in 4 bytes, the
    > encoding is not correct. The value looks something like FFFFXXXX (A706 0204
    > FFFFXXXX).
    >
    > As per ASN encoding, this should be encoded as 00FFFFXXXX (A707 0205
    > 00FFFFXXXX) since ASN encoding does not allow top 9 bit to be either all
    > ones or all zeroes.
    >
    > Has anyone seen this problem?
    >
    > sample Hex dump of the seq-number field from the Authenticator
    >
    > A70402020398 Works
    > A704020207CB Works
    > A7060204FFFFF77F Fails
    > A7060204FFFFFA59 Fails
    > A7060204FFFFF96D Fails
    > A7060204FFFFF3F8 Fails
    >
    >



  3. Re: Java 1.5 is not encoding integers properly

    As per the ASN encoding specifications, all integers must be encoded in
    minimum number of octets.
    This means that the top 9 bits of the encoded string should not be same.

    It is possible that other implementations of ASN encoding have similar bug
    and this encoding error is either not detected or ignored.

    In my case, I am receiving seq-number encoded as FFFFXXXX (A706 0204
    FFFFXXXX) and this is wrong.
    It should be encoded as 00FFFFXXXX (A707 0205 00FFFFXXXX).

    Is my interpretation of rules of the ASN encoding correct?

    "Seema Malkani" wrote in message
    news:4499D248.2050604@sun.com...
    > Sun's implementation of Java GSS/Kerberos implementation is fully
    > interoperable with MIT/Solaris/Linux/Windows GSS/Kerberos implementations.
    > Tokens generated by Java are accepted by all other GSS/Kerberos
    > implementations.
    >
    > I'll look into this, and get back to you.
    >
    > Seema
    >
    > Salil Dangi wrote:
    >> I am using java 1.5 to generate a service ticket token (AP Request) for a
    >> service running on Unisys machines.
    >> This token can not be parsed properly due to ASN encoding errors.
    >>
    >> There is an Authenticator in this AP request.
    >> Within the authenticator, there is an optional field for seq-number of
    >> type integer.
    >> The seq-number is a unsigned integer that can go from 0 to 2**32 -1 with
    >> a random initial value.
    >>
    >> During my sample runs, I saw that Java 1.5 implementation is either
    >> sending an integer encoded in 2 bytes or an integer encoded in 4 bytes.
    >> When this is encoded in 2 bytes, there is no issue. When this is encoded
    >> in 4 bytes, the encoding is not correct. The value looks something like
    >> FFFFXXXX (A706 0204 FFFFXXXX).
    >>
    >> As per ASN encoding, this should be encoded as 00FFFFXXXX (A707 0205
    >> 00FFFFXXXX) since ASN encoding does not allow top 9 bit to be either all
    >> ones or all zeroes.
    >>
    >> Has anyone seen this problem?
    >>
    >> sample Hex dump of the seq-number field from the Authenticator
    >>
    >> A70402020398 Works
    >> A704020207CB Works
    >> A7060204FFFFF77F Fails
    >> A7060204FFFFFA59 Fails
    >> A7060204FFFFF96D Fails
    >> A7060204FFFFF3F8 Fails

    >




  4. Re: Java 1.5 is not encoding integers properly

    >>>>> "Salil" == Salil Dangi writes:

    Salil> As per the ASN encoding specifications, all integers must
    Salil> be encoded in minimum number of octets. This means that
    Salil> the top 9 bits of the encoded string should not be same.

    MIT Kerberos and I think most of the other Kerberos implementations
    out there will accept non-minimal-length BER integers. I agree that
    this is not compatible ith DER and that implementations that generate
    such integers are not conforming to RFC 4120.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: Java 1.5 is not encoding integers properly

    Is MIT implementation only accepting non-minimal-length integers or it is
    also generating non-minimal-length integers?

    If it is generating non-minimal-length integers then that should be
    corrected.

    > Salil> As per the ASN encoding specifications, all integers must
    > Salil> be encoded in minimum number of octets. This means that
    > Salil> the top 9 bits of the encoded string should not be same.
    >
    > MIT Kerberos and I think most of the other Kerberos implementations
    > out there will accept non-minimal-length BER integers. I agree that
    > this is not compatible ith DER and that implementations that generate
    > such integers are not conforming to RFC 4120.
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >




+ Reply to Thread