Re: JGSS: Integrity check on decrypted field failed (31) - Kerberos

This is a discussion on Re: JGSS: Integrity check on decrypted field failed (31) - Kerberos ; What you have is a GSS token using the SPNEGO mechanism that contains a Kerberos AS_REQ message as one of its components. You need to wrap the extracted Kerberos AS_REQ message in a new GSS token using the Kerberos mechanism ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: JGSS: Integrity check on decrypted field failed (31)

  1. Re: JGSS: Integrity check on decrypted field failed (31)

    What you have is a GSS token using the SPNEGO mechanism that contains a
    Kerberos AS_REQ message as one of its components. You need to wrap the
    extracted Kerberos AS_REQ message in a new GSS token using the Kerberos
    mechanism before passing it to acceptSecurityContext(). You also need
    to extract the AS_REP message from the GSS token returned from that call
    and wrap it in a new GSS token using the SPNEGO mechanism before sending
    it to the client. RFCs 1964 and 4121 show how to do this.

    Or, you can use a version of JGSS that understands GSS/SPNEGO as well as
    GSS/Kerberos.

    --David
    --
    W. David Shambroom, Ph.D.
    Security Architect 617.551.2143
    InterSystems Corporation wds@intersystems.com


    > Message: 2
    > Date: Mon, 6 Nov 2006 14:26:20 -0500 (EST)
    > From: "Michael B Allen"
    > Subject: JGSS: Integrity check on decrypted field failed (31)
    > To: kerberos@mit.edu
    > Message-ID: <60406.38.117.185.138.1162841180.squirrel@www.iople x.com>
    > Content-Type: text/plain;charset=iso-8859-1
    >
    > I wrote an SPNEGO Java Servlet Filter that decodes the SPNEGO token,
    > plucks out the krb5 mechToken and passes it to acceptSecContext. Works
    > great on Linux/Jetty. Tomcat on Windows gives me the following exception.
    > Basically it looks like it's failing to decrypt the ticket as if the
    > password was wrong (but it's not). The service account is set for DES
    > only. For the service credential, I manually create a KerberosKey with a
    > plaintext password and enctype of "DES".
    >
    > Before I start doing byte for byte checking can anyone recommend potential
    > reasons for this error?
    >
    > GSSException: Failure unspecified at GSS-API level (Mechanism level:
    > Integrity check on decrypted field failed (31))
    > sun.security.jgss.krb5.Krb5Context.acceptSecContex t(Krb5Context.java:734)
    > sun.security.jgss.GSSContextImpl.acceptSecContext( GSSContextImpl.java:300)
    > sun.security.jgss.GSSContextImpl.acceptSecContext( GSSContextImpl.java:246)
    > com.ibi.security.spnego.SpnegoFilter.doFilter(Spne goFilter.java:262)
    >
    >

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: JGSS: Integrity check on decrypted field failed (31)

    Hi David,

    Can you be more specific? The mechToken in the NegTokenInit of the
    SPNEGO token is a valid GSSAPI token and is in fact no different from
    a raw Kerberos token.

    Also, the filter works fine now. I had to initialize the server credential
    using the more common method used in the tutorials. It's only on Windows
    systems that trying to create a Subject with a KerberosKey from a password
    directly that the said error occurs.

    My understanding at this point is that it is a flaw in Java's GSSAPI
    implementation.

    Thanks,
    Mike

    On Tue, 07 Nov 2006 18:34:46 -0500
    David Shambroom wrote:

    > What you have is a GSS token using the SPNEGO mechanism that contains a
    > Kerberos AS_REQ message as one of its components. You need to wrap the
    > extracted Kerberos AS_REQ message in a new GSS token using the Kerberos
    > mechanism before passing it to acceptSecurityContext(). You also need
    > to extract the AS_REP message from the GSS token returned from that call
    > and wrap it in a new GSS token using the SPNEGO mechanism before sending
    > it to the client. RFCs 1964 and 4121 show how to do this.
    >
    > Or, you can use a version of JGSS that understands GSS/SPNEGO as well as
    > GSS/Kerberos.
    >
    > --David
    > --
    > W. David Shambroom, Ph.D.
    > Security Architect 617.551.2143
    > InterSystems Corporation wds@intersystems.com
    >
    >
    > > Message: 2
    > > Date: Mon, 6 Nov 2006 14:26:20 -0500 (EST)
    > > From: "Michael B Allen"
    > > Subject: JGSS: Integrity check on decrypted field failed (31)
    > > To: kerberos@mit.edu
    > > Message-ID: <60406.38.117.185.138.1162841180.squirrel@www.iople x.com>
    > > Content-Type: text/plain;charset=iso-8859-1
    > >
    > > I wrote an SPNEGO Java Servlet Filter that decodes the SPNEGO token,
    > > plucks out the krb5 mechToken and passes it to acceptSecContext. Works
    > > great on Linux/Jetty. Tomcat on Windows gives me the following exception.
    > > Basically it looks like it's failing to decrypt the ticket as if the
    > > password was wrong (but it's not). The service account is set for DES
    > > only. For the service credential, I manually create a KerberosKey with a
    > > plaintext password and enctype of "DES".
    > >
    > > Before I start doing byte for byte checking can anyone recommend potential
    > > reasons for this error?
    > >
    > > GSSException: Failure unspecified at GSS-API level (Mechanism level:
    > > Integrity check on decrypted field failed (31))
    > > sun.security.jgss.krb5.Krb5Context.acceptSecContex t(Krb5Context.java:734)
    > > sun.security.jgss.GSSContextImpl.acceptSecContext( GSSContextImpl.java:300)
    > > sun.security.jgss.GSSContextImpl.acceptSecContext( GSSContextImpl.java:246)
    > > com.ibi.security.spnego.SpnegoFilter.doFilter(Spne goFilter.java:262)
    > >
    > >

    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >



    --
    Michael B Allen
    PHP Active Directory SSO
    http://www.ioplex.com/
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: JGSS: Integrity check on decrypted field failed (31)

    Mike,

    The mechToken is a Kerberos AS_REQ message, not a GSS token. The
    acceptSecurityContext() method needs a GSS token, as specified in RFC
    1964 section 1.1, not a raw Kerberos AS_REQ message.

    The GSS API and token specification is a wrapper technology. It can
    wrap Kerberos, SPKM, or SPNEGO (probably others too). When using SPNEGO
    the mechanism-specific part of the token can contain a Kerberos AS_REQ
    message as an optimization, but that message by itself is not a GSS token.

    --David

    Michael B Allen wrote:
    > Hi David,
    >
    > Can you be more specific? The mechToken in the NegTokenInit of the
    > SPNEGO token is a valid GSSAPI token and is in fact no different from
    > a raw Kerberos token.
    >
    > Also, the filter works fine now. I had to initialize the server credential
    > using the more common method used in the tutorials. It's only on Windows
    > systems that trying to create a Subject with a KerberosKey from a password
    > directly that the said error occurs.
    >
    > My understanding at this point is that it is a flaw in Java's GSSAPI
    > implementation.
    >
    > Thanks,
    > Mike
    >
    > On Tue, 07 Nov 2006 18:34:46 -0500
    > David Shambroom wrote:
    >
    >> What you have is a GSS token using the SPNEGO mechanism that contains a
    >> Kerberos AS_REQ message as one of its components. You need to wrap the
    >> extracted Kerberos AS_REQ message in a new GSS token using the Kerberos
    >> mechanism before passing it to acceptSecurityContext(). You also need
    >> to extract the AS_REP message from the GSS token returned from that call
    >> and wrap it in a new GSS token using the SPNEGO mechanism before sending
    >> it to the client. RFCs 1964 and 4121 show how to do this.
    >>
    >> Or, you can use a version of JGSS that understands GSS/SPNEGO as well as
    >> GSS/Kerberos.
    >>
    >> --David
    >> --
    >> W. David Shambroom, Ph.D.
    >> Security Architect 617.551.2143
    >> InterSystems Corporation wds@intersystems.com
    >>
    >>
    >>> Message: 2
    >>> Date: Mon, 6 Nov 2006 14:26:20 -0500 (EST)
    >>> From: "Michael B Allen"
    >>> Subject: JGSS: Integrity check on decrypted field failed (31)
    >>> To: kerberos@mit.edu
    >>> Message-ID: <60406.38.117.185.138.1162841180.squirrel@www.iople x.com>
    >>> Content-Type: text/plain;charset=iso-8859-1
    >>>
    >>> I wrote an SPNEGO Java Servlet Filter that decodes the SPNEGO token,
    >>> plucks out the krb5 mechToken and passes it to acceptSecContext. Works
    >>> great on Linux/Jetty. Tomcat on Windows gives me the following exception.
    >>> Basically it looks like it's failing to decrypt the ticket as if the
    >>> password was wrong (but it's not). The service account is set for DES
    >>> only. For the service credential, I manually create a KerberosKey with a
    >>> plaintext password and enctype of "DES".
    >>>
    >>> Before I start doing byte for byte checking can anyone recommend potential
    >>> reasons for this error?
    >>>
    >>> GSSException: Failure unspecified at GSS-API level (Mechanism level:
    >>> Integrity check on decrypted field failed (31))
    >>> sun.security.jgss.krb5.Krb5Context.acceptSecContex t(Krb5Context.java:734)
    >>> sun.security.jgss.GSSContextImpl.acceptSecContext( GSSContextImpl.java:300)
    >>> sun.security.jgss.GSSContextImpl.acceptSecContext( GSSContextImpl.java:246)
    >>> com.ibi.security.spnego.SpnegoFilter.doFilter(Spne goFilter.java:262)
    >>>
    >>>

    >> ________________________________________________
    >> Kerberos mailing list Kerberos@mit.edu
    >> https://mailman.mit.edu/mailman/listinfo/kerberos
    >>

    >
    >


    --
    W. David Shambroom, Ph.D.
    Security Architect 617.551.2143
    InterSystems Corporation wds@intersystems.com
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: JGSS: Integrity check on decrypted field failed (31)

    On Thu, 09 Nov 2006 10:10:56 -0500
    David Shambroom wrote:

    > Mike,
    >
    > The mechToken is a Kerberos AS_REQ message, not a GSS token.


    My understanding is that this statement is wholely incorrect.

    Do you speak binary? I think that's the only way you're going to convince
    me. The following is a comparison of a Kerberos 5 GSSAPI token submitted
    by Firefox and a Kerberos 5 NegTokenInit.mechToken[] from IE.

    $ hexd rawkrb5.bin -r "4,2,9,2,4,4,64"
    00000: 60 82 04 8d |`... |
    00000: 06 09 |.. |
    00000: 2a 86 48 86 f7 12 01 02 02 |*.H...... |
    00000: 01 00 |.. |
    00000: 6e 82 04 7c |n..| |
    00000: 30 82 04 78 |0..x |
    00000: a0 03 02 01 05 a1 03 02 01 0e a2 07 03 05 00 00 |................|
    00010: 00 00 00 a3 82 03 a6 61 82 03 a2 30 82 03 9e a0 |.......a...0....|
    00020: 03 02 01 05 a1 09 1b 07 46 4f 4f 2e 4e 45 54 a2 |........FOO.NET.|
    00030: 1e 30 1c a0 03 02 01 03 a1 15 30 13 1b 04 48 54 |.0........0...HT|

    $ hexd mechkrb5.bin -r "4,2,9,2,4,4,64"
    00000: 60 82 04 99 |`... |
    00000: 06 09 |.. |
    00000: 2a 86 48 86 f7 12 01 02 02 |*.H...... |
    00000: 01 00 |.. |
    00000: 6e 82 04 88 |n... |
    00000: 30 82 04 84 |0... |
    00000: a0 03 02 01 05 a1 03 02 01 0e a2 07 03 05 00 20 |............... |
    00010: 00 00 00 a3 82 03 b4 61 82 03 b0 30 82 03 ac a0 |.......a...0....|
    00020: 03 02 01 05 a1 09 1b 07 46 4f 4f 2e 4e 45 54 a2 |........FOO.NET.|
    00030: 20 30 1e a0 03 02 01 02 a1 17 30 15 1b 04 48 54 | 0........0...HT|

    Is Wireshark lieing to me?

    Mike

    --
    Michael B Allen
    PHP Active Directory SSO
    http://www.ioplex.com/
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: JGSS: Integrity check on decrypted field failed (31)

    Michael,

    If by "speak binary" you mean "parse hex dumps of ASN.1 BER" then yes.
    These are both truncated GSS tokens. See below.

    I don't want to convince you of anything. I was just trying to help,
    but I'll stop now.

    --David

    Michael B Allen wrote:
    > On Thu, 09 Nov 2006 10:10:56 -0500
    > David Shambroom wrote:
    >
    >> Mike,
    >>
    >> The mechToken is a Kerberos AS_REQ message, not a GSS token.

    >
    > My understanding is that this statement is wholely incorrect.
    >
    > Do you speak binary? I think that's the only way you're going to convince
    > me. The following is a comparison of a Kerberos 5 GSSAPI token submitted
    > by Firefox and a Kerberos 5 NegTokenInit.mechToken[] from IE.
    >
    > $ hexd rawkrb5.bin -r "4,2,9,2,4,4,64"


    Sequence tag and length (0x48d = 1165 bytes):
    > 00000: 60 82 04 8d |`... |


    OID tag and length (9 bytes):
    > 00000: 06 09 |.. |


    Kerberos OID:
    > 00000: 2a 86 48 86 f7 12 01 02 02 |*.H...... |


    Token ID, KRB_AP_REQ follows:
    > 00000: 01 00 |.. |


    KRB_AP_REQ begins here:
    > 00000: 6e 82 04 7c |n..| |
    > 00000: 30 82 04 78 |0..x |
    > 00000: a0 03 02 01 05 a1 03 02 01 0e a2 07 03 05 00 00 |................|
    > 00010: 00 00 00 a3 82 03 a6 61 82 03 a2 30 82 03 9e a0 |.......a...0....|
    > 00020: 03 02 01 05 a1 09 1b 07 46 4f 4f 2e 4e 45 54 a2 |........FOO.NET.|
    > 00030: 1e 30 1c a0 03 02 01 03 a1 15 30 13 1b 04 48 54 |.0........0...HT|
    >
    > $ hexd mechkrb5.bin -r "4,2,9,2,4,4,64"
    > 00000: 60 82 04 99 |`... |
    > 00000: 06 09 |.. |
    > 00000: 2a 86 48 86 f7 12 01 02 02 |*.H...... |
    > 00000: 01 00 |.. |
    > 00000: 6e 82 04 88 |n... |
    > 00000: 30 82 04 84 |0... |
    > 00000: a0 03 02 01 05 a1 03 02 01 0e a2 07 03 05 00 20 |............... |
    > 00010: 00 00 00 a3 82 03 b4 61 82 03 b0 30 82 03 ac a0 |.......a...0....|
    > 00020: 03 02 01 05 a1 09 1b 07 46 4f 4f 2e 4e 45 54 a2 |........FOO.NET.|
    > 00030: 20 30 1e a0 03 02 01 02 a1 17 30 15 1b 04 48 54 | 0........0...HT|
    >
    > Is Wireshark lieing to me?
    >
    > Mike
    >

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread