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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] >> >> >>> Message: 2 >>> Date: Mon, 6 Nov 2006 14:26:20 -0500 (EST) >>> From: "Michael B Allen" <[EMAIL PROTECTED]> >>> Subject: JGSS: Integrity check on decrypted field failed (31) >>> To: [email protected] >>> Message-ID: <[EMAIL PROTECTED]> >>> 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 [email protected] >> https://mailman.mit.edu/mailman/listinfo/kerberos >> > > -- W. David Shambroom, Ph.D. Security Architect 617.551.2143 InterSystems Corporation [EMAIL PROTECTED] ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
