Re: JGSS: Integrity check on decrypted field failed (31)
Seema Malkani
problem with the keys used.
When using Java GSS, the Kerberos credentials (TGT and KerberosKey) are
acquired and stored in the JAAS subject. The keys are obtained from your
keytab file, if you configure to use keytab file. It's not clear why you
need to create a KerberosKey object.
Have you created a keytab file or are you using passwords ? Can you
obtain a ticket for this SPN using kinit ? Does this work ?
The JAAS Kerberos configuration option "isInitiator" allows to
distinguish if are want the Krb5LoginModule to be an acceptor only, in
which case the TGT will not be acquired.
Seema
Michael B Allen wrote On 11/08/06 09:01,:
>Well I got the filter to work but I never did figured out the "Integrity
>check on decrypted field failed (31)" error.
>
>I just had to create the server credential using the typical code:
>
> Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");
> Oid krb5Mechanism = new Oid("1.2.840.113554.1.2.2");
> GSSManager manager = GSSManager.getInstance();
> GSSName serverName = manager.createName(spn, krb5PrincipalNameType);
> this.serverCreds = manager.createCredential(serverName,
> GSSCredential.DEFAULT_LIFETIME,
> krb5Mechanism,
> GSSCredential.ACCEPT_ONLY);
> } catch(GSSException ge) {
> throw new ServletException("[SpnegoFilter]", ge);
> }
>
>The bazaar thing about this is this invokes the Krb5LoginModule and gets
>a TGT. I don't need or want a TGT. I don't want to have to supply a JAAS
>conf. I don't want to have to specify where the KDC is.
>
>The problem was the way with which I created the server credential
>before. Basically I created a KerberosKey from a password, put it into
>a Subject and ran doAsPriviledged to call the above code and return the
>GSSCredential. Then I used that credential to create a GSSContext and call
>acceptSecContext. This works with Java on Linux but with Java on Windows
>acceptSecContext yeilds this "Integrity check on decrypted field failed
>(31)" error.
>
>Seema,
>
>Do you work with the Java security group? Can you confirm or deny that
>the above KerberosKey in Subject method should work?
>
>Mike
>
>On Tue, 7 Nov 2006 23:48:03 -0500
>Michael B Allen <mba...@ioplex.com> wrote:
>
>
>
>>I believe this problem must be a bug in Java for Windows.
>>
>>All of the GSS examples use the default credentials of the user running
>>the server. I do not. I created a KerberosKey from a password and acquired
>>the GSSCredential through Subject.doAsPriviledged. Again the Filter works
>>on Linux this way just fine. But apparently Windows is not satisfied when
>>acceptSecContext is called. I can only guess that the Krb5LoginModule is
>>calling into the host using SSPI routines and as a result the behavior
>>is different.
>>
>>Is there any way to tell Java on Windows not to interact with SSPI at
>>all and do everything natively?
>>
>>So, now I'm trying to go through the LoginContext with the Krb5LoginModule
>>but that's far more complicated (and should be totally unnecessary
>>considering I have a keytab) and I'm weeding through errors with jaas.conf
>>syntax, keytab files, etc.
>>
>>Somebody give me a clue please.
>>
>>Mike
>>
>>On Tue, 7 Nov 2006 17:54:50 -0500
>>Michael B Allen <mba...@ioplex.com> wrote:
>>
>>
>>
>>>Hi Seema,
>>>
>>>I have narrowed things down quite a bit. If I use Firefox which uses
>>>raw kerberos tokens I still get the same error which means that this
>>>has nothing to do with SPNEGO. If I run the Filter in Jetty on Linux it
>>>works. So there's something about Tomcat / Windows / Java on Windows. On
>>>site we tried a variety of different versions of Java but the one I'm
>>>trying right now is Java 1.4.2_13.
>>>
>>>The SPNs are mapped correctly and the password in fact correct. I've been
>>>doing a lot of the SSO stuff recently and I'm pretty good at diagnosing
>>>the many problems that can occur.
>>>
>>>I have compared tickets field by field using a packet sniffer (although
>>>I have not resorted to decrypting the encrypted fields yet).
>>>
>>>Do you happen to know if this particular exception is caused by a
>>>problem with the authenticator or decrypting the ticket in general?
>>>
>>>My next step will be to use Configuration.setConfiguration() to explore
>>>the effect of Krb5LoginModule options.
>>>
>>>Can you recommend futher action?
>>>
>>>Thanks,
>>>Mike
>>>
>>>On Tue, 07 Nov 2006 12:16:22 -0800
>>>Seema Malkani <Seema....@Sun.COM> wrote:
>>>
>>>
>>>
>>>>What version of JDK are you using ? Sun's implementation of Java GSS
>>>>includes support for SPNEGO starting from Java SE 6.
>>>>
>>>>Has the SPN been setup correctly ?
>>>>
>>>>Seema
>>>>
>>>>Michael B Allen wrote On 11/06/06 11:26,:
>>>>
>>>>
>>>>
>>>>>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)
>>>>>________________________________________________
>>>>>Kerberos mailing list Kerb...@mit.edu
>>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>>
>>>>>
>>>>>
>>>>>
>>>--
>>>Michael B Allen
>>>PHP Active Directory SSO
>>>http://www.ioplex.com/
>>>________________________________________________
>>>Kerberos mailing list Kerb...@mit.edu
>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>>
>>>
>>--
>>Michael B Allen
>>PHP Active Directory SSO
>>http://www.ioplex.com/
>>________________________________________________
>>Kerberos mailing list Kerb...@mit.edu
>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>
>>
>
>
>
>
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
David Shambroom
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 w...@intersystems.com
> Message: 2
> Date: Mon, 6 Nov 2006 14:26:20 -0500 (EST)
> From: "Michael B Allen" <mba...@ioplex.com>
> Subject: JGSS: Integrity check on decrypted field failed (31)
> To: kerb...@mit.edu
> Message-ID: <60406.38.117.185.138...@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)
Michael B Allen
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
--
Michael B Allen
PHP Active Directory SSO
http://www.ioplex.com/
David Shambroom
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
David Shambroom <david.s...@intersystems.com> 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/
David Shambroom
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 <david.s...@intersystems.com> 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
>