JGSS: Integrity check on decrypted field failed (31)

[David Shambroom]

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 <david.shambroom at intersystems.com> 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 at intersystems.com
>>
>>
>>> Message: 2
>>> Date: Mon, 6 Nov 2006 14:26:20 -0500 (EST)
>>> From: "Michael B Allen" <mba2000 at ioplex.com>
>>> Subject: JGSS: Integrity check on decrypted field failed (31)
>>> To: kerberos at mit.edu
>>> Message-ID: <60406.38.117.185.138.1162841180.squirrel at www.ioplex.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.acceptSecContext(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(SpnegoFilter.java:262)
>>>
>>>
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>
> 
> 

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